• Advertisement

SHilbert

Member
  • Content count

    2194
  • Joined

  • Last visited

Everything posted by SHilbert

  1. Multi pass texturing

    Looks like maybe it's because you're calling SetTexture inside Begin/EndPass. [quote] If the application changes any effect state using any of the [u]Effect::Setx[/u] methods inside of a [b]ID3DXEffect::BeginPass[/b]/[b]ID3DXEffect::EndPass[/b] matching pair, the application must call [u]ID3DXEffect::CommitChanges[/u] to set the update the device with the state changes. If no state changes occur within a [b]ID3DXEffect::BeginPass[/b] and [b]ID3DXEffect::EndPass[/b] matching pair, it is not necessary to call [b]ID3DXEffect::CommitChanges[/b]. [/quote] So one option is to call mFX->CommitChanges(). I don't think you actually need to manually change the texture per pass at all, though. If you just define 3 texture uniforms, instead of the single gTex you have now, and just fill them in with your 3 different textures before you begin drawing, and sample from the right one in each VS, the effect system will sort it all out for you. [b]EDIT:[/b] FYI, to further clean up your effect rendering loop, you can specify the blend modes in your FX file too, by setting states inside the passes: [CODE] technique TerrainMultiTexTech { pass P0 { // Specify the vertex and pixel shader associated with this pass. vertexShader = compile vs_2_0 TerrainMultiTexVS(); pixelShader = compile ps_2_0 TerrainMultiTexPS0(); AlphaBlendEnable = FALSE; } pass P1 { // Specify the vertex and pixel shader associated with this pass. vertexShader = compile vs_2_0 TerrainMultiTexVS(); pixelShader = compile ps_2_0 TerrainMultiTexPS1(); AlphaBlendEnable = TRUE; SrcBlend = SRCALPHA; DestBlend = INVSRCALPHA; } pass P2 { // Specify the vertex and pixel shader associated with this pass. vertexShader = compile vs_2_0 TerrainMultiTexVS(); pixelShader = compile ps_2_0 TerrainMultiTexPS2(); AlphaBlendEnable = TRUE; SrcBlend = SRCALPHA; DestBlend = INVSRCALPHA; } } [/CODE]
  2. [Dx8] Texture & Blending

    [quote name='testt' timestamp='1340969502' post='4953922'] I don't understand why I used D3DRS_DESTBLEND=D3DBLEND_ONE to rendering the texture and I don't tried D3DRS_SRCBLEND=D3DBLEND_ONE.. It's so obvious now that I look stupid [/quote] I didn't even notice that it was [b]DEST[/b]BLEND in your post and not [b]SRC[/b]BLEND until you pointed it out. Easy mistake to make. [quote name='testt' timestamp='1340969502' post='4953922'] If that doesn't bother you I keep your code in C++, I think this is a good example for me when I will turn to this language. [/quote] No problem. A third of that code is just from a quick start tutorial somewhere on the internet anyway, to make the window & device & such. [quote name='testt' timestamp='1340969502' post='4953922'] However, I have a last question because it's the only thing I didn't quite understand. The D3DTA_ALPHAREPLICATE doesn't allow to use vertex color because he take the informations only in the texture ? [/quote] When you do something like D3DTA_TEXTURE | D3DTA_ALPHAREPLICATE, it means it takes the (r,g,b,a) from the texture (the D3DTA_TEXTURE part) and turns it into (a,a,a) (the D3DTA_ALPHAREPLICATE part.) So when you do this: [source lang="cpp"] g_device->SetTextureStageState(0, D3DTSS_COLOROP, D3DTOP_MODULATE); g_device->SetTextureStageState(0, D3DTSS_COLORARG1, D3DTA_TEXTURE); g_device->SetTextureStageState(0, D3DTSS_COLORARG2, D3DTA_TEXTURE|D3DTA_ALPHAREPLICATE); [/source] It means: colorarg1 = (r,g,b) from the texture colorarg2 = sample the alpha from the texture and produce a triplet (a,a,a) modulate = the output is colorarg1 * colorarg2 = (r,g,b) * (a,a,a) = (r*a, g*a, b*a) So if the texture at that point is (r,g,b,a) then the overall of that stage is (r*a, g*a, b*a, a). (The alpha processing is just left as default.)
  3. Multi pass texturing

    Looks like you have alpha blending turned on for each pass, but the alpha value your pixel shaders are outputting is diffuse.a, which is probably just 1. So each pass is drawing opaquely over the previous one. I'm not sure why you're not doing this all in one pass in a single pixel shader, though -- it doesn't seem like you'd run out of instruction slots or textures? I might be wrong though. If you do want to do multipass, you probably want to draw the first pass w/ alpha blending turned off, without even referring to the blend map. Then, for the subsequent passes, turn on alpha blending, and instead of multiplying the tiled texture's color by the green or blue channel from the blend map, you use the green or blue channel as the alpha component you return from the pixel shader. Not sure why your texture order is swapped (i.e. why stone is mapped to blue instead of green) though.
  4. [Dx8] Texture & Blending

    I figured this may be more easily expressed in code so I put it together using DX9 and C++ (I haven't got VB6 or a DX8 SDK, sorry.) But the code should still be easy enough to read since it's mostly the Direct3D parts that matter. Here it is: [url="http://shilbert.com/files/BlendTest.zip"]http://shilbert.com/...s/BlendTest.zip[/url] This is the interesting part: [source lang="cpp"]void Draw() { g_device->BeginScene(); // Common states we always use g_device->SetRenderState(D3DRS_CULLMODE, D3DCULL_NONE); g_device->SetRenderState(D3DRS_LIGHTING, FALSE); g_device->SetRenderState(D3DRS_ALPHABLENDENABLE, TRUE); // Render to 512x512 texture g_device->SetRenderTarget(0, g_rttSurf); D3DXMATRIX proj512x512; D3DXMatrixOrthoOffCenterRH(&proj512x512, 0, 512, 512, 0, -10, 10); g_device->SetTransform(D3DTS_PROJECTION, &proj512x512); // Clear all components to zero g_device->Clear(0, NULL, D3DCLEAR_TARGET, D3DCOLOR_ARGB(0,0,0,0), 0, 0); // Premultiply alpha in the source texture using texture stage g_device->SetTextureStageState(0, D3DTSS_COLOROP, D3DTOP_MODULATE); g_device->SetTextureStageState(0, D3DTSS_COLORARG1, D3DTA_TEXTURE); g_device->SetTextureStageState(0, D3DTSS_COLORARG2, D3DTA_TEXTURE|D3DTA_ALPHAREPLICATE); // Set blend mode to (ONE, INVSRCALPHA) g_device->SetRenderState(D3DRS_SRCBLEND, D3DBLEND_ONE); g_device->SetRenderState(D3DRS_DESTBLEND, D3DBLEND_INVSRCALPHA); // Draw textures 1 & 2 DrawTexturedQuad(g_tex1, 0, 0, 512, 512); DrawTexturedQuad(g_tex2, 0, 0, 512, 512); // Now switch to the main render target (1024x512) g_device->SetRenderTarget(0, g_defaultRT); D3DXMATRIX proj1024x512; D3DXMatrixOrthoOffCenterRH(&proj1024x512, 0, 1024, 512, 0, -10, 10); // Clear to some random color g_device->Clear(0, NULL, D3DCLEAR_TARGET, D3DCOLOR_XRGB(0, 0, 255), 0, 0); // Reset texture stage settings to default g_device->SetTextureStageState(0, D3DTSS_COLOROP, D3DTOP_MODULATE); g_device->SetTextureStageState(0, D3DTSS_COLORARG1, D3DTA_TEXTURE); g_device->SetTextureStageState(0, D3DTSS_COLORARG2, D3DTA_CURRENT); g_device->SetTransform(D3DTS_PROJECTION, &proj1024x512); // Left side. (render to texture side) // Draw the back texture, 0.png -- use normal alpha blending // (doesn't matter since it's opaque) g_device->SetRenderState(D3DRS_SRCBLEND, D3DBLEND_SRCALPHA); g_device->SetRenderState(D3DRS_DESTBLEND, D3DBLEND_INVSRCALPHA); DrawTexturedQuad(g_tex0, 0, 0, 512, 512); // Draw the offscreen texture we have generated. // It uses premultiplied alpha so we have to blend appropriately g_device->SetRenderState(D3DRS_SRCBLEND, D3DBLEND_ONE); g_device->SetRenderState(D3DRS_DESTBLEND, D3DBLEND_INVSRCALPHA); DrawTexturedQuad(g_rtt, 0, 0, 512, 512); // Right side. (control side) // Now go back and draw each texture on top of one another w/ default alpha blending. g_device->SetRenderState(D3DRS_SRCBLEND, D3DBLEND_SRCALPHA); g_device->SetRenderState(D3DRS_DESTBLEND, D3DBLEND_INVSRCALPHA); DrawTexturedQuad(g_tex0, 512, 0, 512, 512); DrawTexturedQuad(g_tex1, 512, 0, 512, 512); DrawTexturedQuad(g_tex2, 512, 0, 512, 512); // Done with scene, swap buffers, etc. g_device->EndScene(); g_device->Present(NULL, NULL, NULL, NULL); }[/source] I'm drawing to the offscreen render target every frame, but it's the same idea as what you have. Also I did it with a single texture stage, because there is no reason to multiply in vertex color for this example. Basically when drawing to the offscreen render target: (1) clear to black w/ zero alpha (2) set up texture stage 0 to multiply color components by alpha (3) draw your textures w/ src=one, dest=invsrcalpha Then when drawing to the target: (1) reset all texture stages to default (2) draw your checkerboard backdrop w/ an alpha blend (src=srcalpha, dest=invsrcalpha) or no blending at all (3) draw the render target texture using src=one, dest=invsrcalpha I hope that helps. Here's a screenshot of what it looks like: [url="http://shilbert.com/pics/blendtest.png"]http://shilbert.com/pics/blendtest.png[/url]
  5. [Dx8] Texture & Blending

    [quote name='testt' timestamp='1340748026' post='4953154'] Hi and sorry for my absence (I had some problems with my pc). [/quote] No worries! [quote name='testt' timestamp='1340748026' post='4953154'] Edit : The problem with blending of two colors has been resolved, there remains the problem of alpha too low.. See [url="http://hpics.li/130ab20"]here[/url]. [/quote] Hmm, it looks like it is a lot closer! It's like somehow it's rendering as if the alpha is squared (i.e., always less than it ought to be unless alpha = 1.) It's almost as if the alpha is getting premultiplied by itself along with the color parts. Could you maybe post the source as it is now? I'd like to take a look at all of the render states together.
  6. Slow parallel code

    [quote name='Narf the Mouse' timestamp='1340734312' post='4953086'] I'll check if it's the garbage collector - Does anyone know of a free/cheap memory profiler? Manually checking probably wouldn't be quite as easy. [/quote] [url="http://www.microsoft.com/en-us/download/details.aspx?id=16273"]CLR Profiler[/url] is good and free. I seem to remember there being some trick to making it work with XNA but I don't recall what it was at the moment. It will tell you what you're allocating, how much, where and when. You can use the the performance counters exposed by .NET to view what the GC is doing. Basically you go start->run "perfmon.exe" and add counters from under ".NET CLR Memory" to your graph. You can set it up to only show GC info for your specific program too. [url="http://msdn.microsoft.com/en-us/library/x2tyfybc.aspx"]http://msdn.microsof...y/x2tyfybc.aspx[/url] [url="http://blogs.msdn.com/b/maoni/archive/2004/06/03/148029.aspx"]http://blogs.msdn.co.../03/148029.aspx[/url] Also, one trick I have used is to just make a single object that is only referenced via a WeakReference, and every frame check if that WeakReference's Target is now null. In my game I plot these events on a scrolling graph and their frequency tells me how often gen0 collections are happening, which tells me how much garbage I am generating per frame. But that method requires more game-specific setup than the CLR Profiler/Performance Counter route.
  7. [Dx8] Texture & Blending

    [quote name='testt' timestamp='1340563808' post='4952391'] Yes, I know it's possible, but I don't understand exactly how Shilbert told me to do that. Use the same texture in 2 stages to separate opaque pixel and transparent pixel (with a different blending operation for each) or 2 textures in 2 stages for blending between them ? [/quote] The same texture in 2 stages. The goal is to multiply the texture's normal RGB values by the texture's A value before it even gets to the blending stage. This makes the your texture effectively have "premultiplied alpha" at runtime, so you don't have to do it at or before load time. This isn't a pre-pass step, it's something you do every render. It's been ages since I worked with texture stages but I am pretty sure this sort of approach will work. If you don't care about vertex colors you can also do it in one stage like this, I think: (Stage 0) Texture = (your source texture) [left][background=rgb(250, 251, 252)]D3DTSS_COLOROP = D3DTOP_MODULATE[/background][/left] [left][color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif][size=3][background=rgb(250, 251, 252)]D3DTSS_COLORARG1 = D3DTA_TEXTURE[/background][/size][/font][/color][/left] [left][color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif][size=3][background=rgb(250, 251, 252)]D3DTSS_COLORARG2 = D3DTA_TEXTURE | D3DTA_ALPHAREPLICATE[/background][/size][/font][/color][/left]
  8. Order or 2D drawable entities

    Assuming you are working in C# since you mentioned avoiding LINQ. My first try would be this: Collect all the entities that are onscreen into a List, and use List.Sort with a custom Comparison<T> method. Don't use bubble sort! If you Clear() and re-used the visible entity list instance every frame, you will not generate any unnecessary garbage this way. I wouldn't try to do any schemes to sort only while entities move unless you can't get good enough performance this way, just because it is far simpler code to just sort right before rendering. In my experience you can sort a lot of objects this way and it will still be fast.
  9. [quote name='MARS_999' timestamp='1340418789' post='4951899'] Well so far from what I can determine, the std::multimap is faster when I start adding lots of objects. If one a few about the same. Say player clicks on object and camera is at an angle where their could be 10 objects in a line one behind each other when doing the ray test, this shouldn't happen very often but seeing what I see so far, I am switching to the multimap version. [/quote] If your worst case is literally finding the closest of a list of 10 objects once per frame, you could do anything and it would be fast. On the other hand, if you can rule out raycasts before even doing them, that is definitely worth doing. Like, if you know that your closest object had a distance of 6 meters, and you get to an object where the distance from the camera to the surface of its bounding sphere is 7 meters, you don't have to do any ray casts vs. its geometry at all, you can just throw it out.
  10. Slow parallel code

    [quote name='Narf the Mouse' timestamp='1340411728' post='4951874'] At the moment, I'm not working on instancing, and I'd really like to know why the parallel code experiences a sudden drop in speed. [/quote] You mentioned that the code chunk you posted takes 48% of the time in one test. Do you know for sure that it is the part that is growing out of proportion to the other part as [i]x[/i] increases? Like, as you increase [i]x[/i] does that percentage go up, or down, or stay the same? I would time the first parallel loop, the second parallel loop, and your actual rendering code, all separately, and see which one is growing faster than the others as you increase [i]x[/i]. You don't even need SlimTune, just use a System.Diagnostics.Stopwatch and draw the times, or percentages of frametime, on the screen. That way you can at least verify that you are targeting exactly the right section. Also, if you are not doing it already, I would make sure you compare tests with the same percentage of objects visible -- either all, or none, or some constant value like 50%. If you compare 60% objects visible at x=27 to 40% objects visible at x=28 you will see changes in the relative timing of different sections that are only based on that percentage, not on [i]x[/i]. Also consider memory allocation and garbage collection. As you start allocating bigger chunks of RAM it starts getting more and more expensive, and the GC may start to thrash more and more often. One [b]VERY SUSPICIOUS[/b] fact is that an allocation of 27^3 32-bit references is on the order of the size things start getting put in a separate large object heap (85,000 bytes.) I wrote a program to time how long it took per allocation averaged over 100,000 allocations, and I get this chart: [img]https://dl.dropbox.com/u/514853/permanent/allocscale2.png[/img] [i](EDIT: The graph is actually milliseconds for a pair of allocations -- first allocating an array of that size, and then calling ToList on it.)[/i] Notice that the Y axis is milliseconds, though -- so if it is affecting you it is probably because the number of objects in your heap is much larger than my test program's, or you allocate many times per frame. Maybe try and see how frequently GCs are happening. [url="http://msdn.microsoft.com/en-us/library/x2tyfybc.aspx"]There are some performance counters[/url] that can tell you lots of details about this. GCs can strike anywhere in your main loop even if they're caused by allocations in a localized position so it would be useful to rule that out first.
  11. [Dx8] Texture & Blending

    You should be able to accomplish it with with texture stage states. For example, I think if you do add second color stage with D3DTSS_COLOROP = D3DTOP_MODULATE D3DTSS_COLORARG1 = D3DTA_CURRENT D3DTSS_COLORARG2 = D3DTA_TEXTURE | D3DTA_ALPHAREPLICATE ...you can get the same effect. You only need to use this extra stage when rendering from non-premultiplied alpha textures, like your textures from 1.png and 2.png. You can also do the premultiplication 'offline' by modifying your texture files before you load them, or lock the texture after loading and do the premultiplication then. Or you could switch to DX9, which is close to 10 years old at this point and enjoys near universal support. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] Don't know if that is feasible in VB6 though, I don't know much about that ecosystem. [url="http://www.vbforums.com/showthread.php?t=605201"]This guy[/url] seems to have a library for using DX9 in VB (see post #14.)
  12. Geez, that is some poorly worded documentation. I [i]think[/i] what it is saying is that if you pass NULL, then you get the situation described in the description column. As for the second column, I think the & !( ... ) is a horribly poor way of saying "bitwise anded with the bitwise inverse of ...." -- kind of weird they used ! instead of ~. That explains why "Vertices are ordered in a counterclockwise direction around each triangle." is next to "& !( D3DXTANGENT_WIND_CW )" -- D3DXTANGENT_WIND_CW is [i]not[/i] set, so the ordering must be counterclockwise. So basically [i]none [/i]of the flags mentioned in that column are set by default. All of the flags have a nonzero value, so if you pass NULL for the flags value you will of course have provided none of the flags. I don't think you want to specify all the flags since some of them are mutually exclusive, but I don't know what to recommend specifically. It does sound like you want to avoid passing D3DXTANGENT_CALCULATE_NORMALS though.
  13. Issues with Occlusion Queries

    Are only the occlusion test models cubes or are the actual models cubes as well? Speed wise, occlusion queries only really make sense if the cost of doing the query is a lot less than the cost of just drawing the thing(s) it represents in the first place. For example, doing an occlusion query where you draw a simple bounding box (very cheap) in order to check if you need to draw an entire city block (very expensive if the geometry is complicated) is probably a good trade-off. Doing an occlusion query where you draw a single cube in order to avoid drawing another single cube, all of the above repeated up to 15,000 times, is probably not going to be effective. Even if you have more complicated models the sheer overhead of executing thousands of occlusion queries could make the speed suffer. If you are trying for speed when looking at the entire scene, I would first say to look into an instancing strategy to achieve better batching. 15,000 draw calls is going to be inherently slow even if you are drawing simple things. Getting occlusion queries right is tricky. If you still want to do the occlusion queries, it would probably be more worthwhile to do 1 occlusion query for a group of [i]many [/i]nearby models, by drawing the group's bounding box -- that way even if the cost of drawing a model is the same as the cost of a query you can potentially spend 1 draw to save 100 draws. Some other miscellaneous thoughts:[list] [*]Is there more to your drawing code? It looks like you draw your models inside the occlusion query Begin/End, which doesn't make much sense to me. [*]You don't want to be making occlusion queries unless you know the object in question is within your view frustum, otherwise the query is doomed from the start. [*]I'm confused why you are drawing a wireframe for your occlusion test object. You should probably be drawing a solid bounding volume or else you are going to get some cases where the occlusion query reports zero pixels when there really might be some. I can see why you would draw the final objects as wireframes though, just to see if the occlusion tests are actually working. [*]Might be worth reading what Shawn Hargreaves says in this thread on the XNA forums: [url="http://forums.create.msdn.com/forums/p/6244/33016.aspx"]http://forums.create...6244/33016.aspx[/url] [/list]
  14. pixel shader input SV_Position

    [quote name='lomateron' timestamp='1340422743' post='4951912'] I want to understand very well how POSITION is tranformed to SV_POSITION [/quote] [b]EDIT:[/b] MJP's post below made me realize I should emphasize an important point: [font=courier new,courier,monospace]SV_Position[/font] is a semantic tag that means [i]different things at different points[/i]. As an output from your vertex shader it is a set of homogenous coordinates. As MJP says below, as the input to the vertex shader it is in screen coordinates! As for the "transform", you get to do any extra transformation you want in your vertex shader! In the case of the shader you posted, there is no transformation at all, you are just returning the [font=courier new,courier,monospace]Pos [/font]value the same as you received it. So they will be identical. And then the screen space transformation MJP describes occurs before it gets to your pixel shader. [quote] I alrewady know that if float4 Pos is (-1,1,0,1) that will mean top-left of screen, (1,1,0,1) that will be top-right of screen...etc so i wanna know how it is transformed and what the values will mean. [/quote] So, the position at this point is in [i]homogenous coordinates[/i] which means that for a given ([i]x,y,z,w[/i]), the final value [i]w[/i] implicitly divides all the others to obtain the final [i]normalized device coordinates[/i]. The division operation is helpful for perspective projection since it involve a divide that you can't accomplish just with normal matrix algebra. So, the homogenous coordinates (-1,1,0,1) really mean (-1,1,0), and (1,0,1,5) really means (0.2,0,0.2). In D3D the normalized device coordinates ([i]x,y,z[/i]) form a 3D cube like so: x: -1 (left of screen) to 1 (right) y: -1 (bottom of screen) to 1 (top) z: 0 (near) to 1 (far) The z-value is used for depth buffering. You will also hear of the homogenous coordinates or normalized device coordinates described as being in "clip space" or as "clip space coordinates," since that is the space in which triangle clipping is performed.
  15. [Dx8] Texture & Blending

    So if I am interpreting you correctly, the problem is that doing this sequence: [quote] device.RenderTarget = DeviceBuffer Draw texture 0 w/ SRCBLEND=SRCALPHA, DESTBLEND=INVSRCALPHA device.RenderTarget = (an offscreen texture, which starts at transparent black, all values = 0x00000000) Draw texture 1 w/ SRCBLEND=SRCALPHA, DESTBLEND=INVSRCALPHA Draw texture 2 w/ SRCBLEND=SRCALPHA, DESTBLEND=INVSRCALPHA device.RenderTarget = DeviceBuffer Draw offscreen texture w/ SRCBLEND=SRCALPHA, DESTBLEND=INVSRCALPHA [/quote] is not equivalent to this sequence: [quote] device.RenderTarget = DeviceBuffer Draw texture 0 w/ SRCBLEND=SRCALPHA, DESTBLEND=INVSRCALPHA Draw texture 1 w/ SRCBLEND=SRCALPHA, DESTBLEND=INVSRCALPHA Draw texture 2 w/ SRCBLEND=SRCALPHA, DESTBLEND=INVSRCALPHA [/quote] And that makes sense, because they aren't equivalent! If you want to composite two transparent textures into one transparent texture, you are better off working all in pre-multiplied alpha -- both with the loaded textures and the offscreen destination texture. That is, modify your source textures so the R, G, B values are already pre-multiplied by the A values, and draw everything using D3DRS_SRCBLEND=D3DBLEND_ONE and D3DRS_DESTBLEND=D3DBLEND_INVSRCALPHA. If you don't work in pre-multiplied alpha the equation is harder to capture with simple blend operators. You may be able to avoid pre-multiplying the alpha on your [i]source textures[/i] by rendering them with separate blending functions for the color channels & the alpha channel -- use these settings: [quote] D3DRS_SRCBLEND=D3DBLEND_SRCALPHA D3DRS_DESTBLEND=D3DBLEND_INVSRCALPHA, D3DRS_SEPARATEALPHABLENDENABLE = TRUE D3DRS_SRCBLENDALPHA=D3DBLEND_ONE D3DRS_DESTBLENDALPHA=D3DBLEND_INVSRCALPHA. [/quote] When drawing the [i]offscreen texture to the final device [/i]buffer you must disable the separate alpha blending & just use D3DRS_SRCBLEND=D3DBLEND_ONE, D3DRS_DESTBLEND=D3DBLEND_INVSRCALPHA. I'm not sure if D3D8 supports this feature though -- I only have the D3D9 docs handy.
  16. [quote name='MARS_999' timestamp='1340375592' post='4951744'] I honestly don't know what you are needing or looking for info on this, it's just a simple insert()... [code] pickedObjects.insert(double, Obj*); //Obj*just an address not new'd //later on pickedObjects.begin()->first to check the dist pickedObjects.being()->second to assign that pointer to selected object.... [/code] Not sure what else I can say nothing complex here people.... [/quote] I might be misinterpreting what you are talking about here, but if you are doing this for [i]object picking[/i], like having the user click in a window to select an object, and you only ever need to know the single object with the smallest distance, you don't need a priority_queue [i]or[/i] a multimap. You just need to remember the currently closest object and its distance, and update those values if you find an even closer one. Again, not sure if that is your use case, though.
  17. Where should I store data?

    You could look into SQLite. SQLite is written in C but there are a few ways to use it from C#: [url="http://system.data.sqlite.org/index.html/doc/trunk/www/index.wiki"]http://system.data.sqlite.org/index.html/doc/trunk/www/index.wiki[/url] provides .NET bindings to SQLite. [url="http://code.google.com/p/csharp-sqlite/"]http://code.google.com/p/csharp-sqlite/[/url] is a C# re-implementation (or more like a translation) of SQLite. SQLite is absurdly portable and well-tested, and it's designed for embedding into applications (there is no separate server process.)
  18. The GDNet Birthday thread

    [quote name='Ravuya' timestamp='1308186035' post='4823874'] If anyone makes floorcaek I swear I am not cleaning it up this time. [/quote] [img]http://shilbert.com/pics/birthdayturtle.jpg[/img] Floorcaek for everyone!
  19. Issues with XAudio2 & mono Ogg Vorbis

    [quote name='Soul Reaver' timestamp='1305724515' post='4812499'] [quote name='SHilbert' timestamp='1305690239' post='4812241'] [quote name='Soul Reaver' timestamp='1305578678' post='4811624'] OAPipeline ASSERT: (UNWORD)pSRCParameters->pvSrc (null)izeof(INT16) == 0, {OAPIPELINE::ResampleLinearFromInt16MonoSse2, Line 1714} [/quote] Given the position of that (null), it looks like it's meant to be: OAPipeline ASSERT: (UNWORD)pSRCParameters->pvSrc %sizeof(INT16) == 0, {OAPIPELINE::ResampleLinearFromInt16MonoSse2, Line 1714} That is, it's checking if pSRCParameters->pvSrc is aligned to 16-bit boundaries. Perhaps a buffer you are passing in is not aligned this way -- that is, the buffer's address is not divisible by 2. That doesn't explain why it worked with stereo, because that probably requires even more strict alignment, but it might be worth checking out. [/quote] Okay I'm confused now. I opened the audio file in an editor and resampled it to 16bit, which was displayed before already. Now it's played without any issues, even in debug mode. What strikes me, is that I thought Vorbis uses a float format internally and the returned format is decided by the "word"-parameter in the Read()-functions. I would be grateful if somebody could elaborate on that. [/quote] If it's happening only some of the time, it definitely sounds like an alignment problem. Do you still have the file that caused the problem originally? I would look at the value of the pointer to the buffer you're passing into SubmitSourceBuffer (or wherever) in the debugger, or print it to the console. If it's odd when it fails, and even when it works, you have an alignment problem. I'm suspecting Xaudio2 has a requirement that your data buffers are aligned to the sample size, or sample size * channel count. If you do find out this is a problem, you should look at how you're getting the pointer to the buffer to give Xaudio -- if you new[] or malloc the buffer yourself, it's always going to be at least 4-byte aligned on windows, so you must be giving it an address into the middle of an existing buffer. EDIT: To be clear, when I'm talking about buffer alignment, I'm talking about the buffer pointed to by your XAUDIO2_BUFFER's pAudioData field, not the address of the XAUDIO2_BUFFER structure itself.
  20. scripting security issues

    Some other things that you should be aware of are things like infinite loops in scripts, or scripts with runaway memory allocation (which can potentially crash the process.) These don't have as much potential to do malicious things to the host system but can still ruin the experience. Also, if you're allowing user scripts on a server, these types of things could easily take down the server without violating the 'sandbox' per se.
  21. Issues with XAudio2 & mono Ogg Vorbis

    [quote name='Soul Reaver' timestamp='1305578678' post='4811624'] OAPipeline ASSERT: (UNWORD)pSRCParameters->pvSrc (null)izeof(INT16) == 0, {OAPIPELINE::ResampleLinearFromInt16MonoSse2, Line 1714} [/quote] Given the position of that (null), it looks like it's meant to be: OAPipeline ASSERT: (UNWORD)pSRCParameters->pvSrc %sizeof(INT16) == 0, {OAPIPELINE::ResampleLinearFromInt16MonoSse2, Line 1714} That is, it's checking if pSRCParameters->pvSrc is aligned to 16-bit boundaries. Perhaps a buffer you are passing in is not aligned this way -- that is, the buffer's address is not divisible by 2. That doesn't explain why it worked with stereo, because that probably requires even more strict alignment, but it might be worth checking out.
  22. [quote name='AvCol' timestamp='1305669796' post='4812120'] [quote name='SHilbert' timestamp='1305654079' post='4812006'] I don't know the details of their particular use case, but I would guess they are using a linked list because you can do constant time insertions or deletions anywhere in the list. [/quote] Well the thing is the GPU has no allocator so something like deletions is impossible without quickly running out of memory. Insertions are possible but jumping from node to node on a gpu is far too slow. This is why when sorting each pixel's list they copy it over to a temp array first. Their implementation is thus: They have one continuous block of memory as an HLSL structured buffer that stores some structure plus an index into that buffer. They then have a second buffer which simply stores an index for each pixel into the first buffer. I will call these the linked list buffer and the pointer buffer. Their allocator if it can be called that just points to the next unoccupied space in the linked list buffer (i.e it is just one atomic counter). Whenever a new fragment is drawn (anywhere on the screen) it needs to be added to the linked list buffer. This is done in three steps 1) Set the new node's link (the new node is at linked_list_buffer[allocator_counter] ) to the value in the pointer buffer for this pixel 2) Set the pointer buffer for this pixel to the allocator's counter 3) Increment the allocator counter. As you can see their allocator can not track where free memory is so deletions would make memory run out very quickly. Besides, as I mentioned earlier jumping from node to node and modfiying their links is too slow on the GPU so they recommend to never do this. What they are using it for is an A-buffer. They could have just as easily declared a fixed 32 floats per pixel but opted to use a linked list like structure instead, and I am wondering why. Originally I thought it was because they were relying on the fact that a linked list would use less memory 99% of the time as not each pixel has 32 triangles drawn on it every frame, but then I found out you had to declare a fixed amount of memory anyway, In fact, you have to reserve more memory to get the same amount of accuracy cause you have to store the link, not to mention that each pixel needs its own start node pointer (just an index into the big pre-allocatied buffer). Now I doubt that that's the whole story cause the guys at AMD are probably pretty smart, I am just wondering what they know that I do not.I don't see any advantage to using a gpu linked list. [/quote] I'd be interested in a link to these slides, if they're publically available -- it sounds like an interesting topic. I could probably get them myself from the GDC Vault if I could manage to look up my password. Having not seen them, though, my guesses are: [list=1][*]There may still be less RAM used (or at least touched per frame) overall anyway, because it may be the case that most pixels need far less than 32 linked list nodes (although you'd think they'd still have to prepare for the worst case!);[*]It may be more cache friendly, because if you store 32 slots per pixel, one after another, and only 20% are used, you have a lot of unused RAM in between your used RAM. Also, with fixed buffers your writes end up splayed all over the place, instead of one after the other; although linked lists display this behavior when reading back.[/list] I'm putting my bets on it being more compact or cache efficient for their particular case, because it does seem like an odd structure to use if they didn't have a good reason.
  23. [quote name='l0k0' timestamp='1305648892' post='4811978'] OK, after more hacking away at it, I find out the issue with the Texture Coordinates. I wasn't wrapping or clamping them when doing my calculations, so this was entirely my fault. It now works in conjunction with spritebatch, the only possible exception being with the depth based rendering. [/quote] Also, do you mean you modified the texture coordinates you are drawing with now, or you just fixed the texture addressing state you're drawing with? Because you should be able to just modify the appropriate SamplerState.AddressU/AddressV value (or do the equivalent thing in an effect file) so they wrap instead of clamp. You shouldn't have to modify the actual vertex data you're sending to the hardware. Apologies if I misunderstood and you're already doing that
  24. [quote name='l0k0' timestamp='1305647501' post='4811967'] 3) I like to use front-to-back depth based rendering, as is enabled in spritebatch. How might I accomplish this so render depths are correct for everything? [/quote] There are a few ways to do sorting: [list=1][*]Always explicitly render things back to front[*]If you never use blending (only fully opaque triangles or alpha test) you can use a Z-buffer for this, assuming you set it up properly.[*]Sort your objects before drawing them.[/list] There are a variety of ways to accomplish sorting, but the simplest to start out with is that you add everything you are going to draw to a list (e.g. List<TexturedPolygon>) and sort it by depth (e.g. List.Sort() with a custom comparison criteria that compares depths.) There are more advanced things you can get into if you have performance issues, like radix sorts which are O(k n) instead of O(n log n), or if your game only has a small number of discrete depths objects can be drawn at (e.g. background/enemies/player/foreground) you can keep separate lists for each, which means you don't have to sort them at all, just draw the lists in the correct order. However, in my experience 2D games rarely have enough things on screen to make a simple depth sort take up a lot time.
  25. [quote name='AvCol' timestamp='1305636812' post='4811917'] I was looking up depth peeling type algorithms for rendering shadow volumes in fog and then noticed that this is really the same sort of thing you do for OIT. So I had a closer look at AMD's slides from last year's GDC explaining what they did in the mecha demo. The thing I don't get about it is that when you are creating a buffer resource in direct x you have to declare a size to the buffer right? Sure enough in AMD's slides they say when declaring the UAV to store the linked list nodes the buffer "must be large enough to store all fragments". But isn't the whole point of the linked list so that it *doesn't* use a fixed amount of memory? So why use linked lists if they use a fixed amount of memory anyway? [/quote] I don't know the details of their particular use case, but I would guess they are using a linked list because you can do constant time insertions or deletions anywhere in the list.
  • Advertisement