Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 04 Mar 2011
Offline Last Active Oct 26 2015 07:40 AM

#5224253 Stream Leaks in SharpDX

Posted by on 18 April 2015 - 06:20 PM

Well for what I'm doing, I wasn't really worried about efficiency at the moment.  I just wanted to get it to stop crashing in the simplest way possible.  So now I gave the buffer its own using, and that fixed it.


Be aware that that isn't the proper way to do it. Doing it right is rather easy and a habit well worth getting into.

#5224218 Stream Leaks in SharpDX

Posted by on 18 April 2015 - 02:49 PM

buffer = new Buffer...


You're creating a new buffer every frame. Use map and unmap instead. You want to create a buffer on the GPU, and reuse that every frame.

#5223459 Culling in SharpDX

Posted by on 15 April 2015 - 10:37 AM

Here is an example of switching the raster state and where that happens during the render phase. Every time you want something different than you have, you change the state. Here I wanted to reverse the winding temporarily to reuse data:

            Game.GraphicsDevice.ImmediateContext.Rasterizer.State = rasterStateReverseWinding;
            foreach (HexMapChunk chunk in chunksInView) //chunksInView determined in update function

            Game.GraphicsDevice.ImmediateContext.Rasterizer.State = rasterStateSolid;

#5223410 Culling in SharpDX

Posted by on 15 April 2015 - 07:30 AM

Is this DX11 or DX9? In DX11 you can cull both ways or no cull.

            RasterizerStateDescription renderStateDesc = new RasterizerStateDescription
                CullMode = CullMode.Back,
                DepthBias = 0,
                DepthBiasClamp = 0,
                FillMode = FillMode.Solid,
                IsAntialiasedLineEnabled = false,
                IsDepthClipEnabled = true,
                IsFrontCounterClockwise = false,
                IsMultisampleEnabled = true,
                IsScissorEnabled = false,
                SlopeScaledDepthBias = 0
            rasterStateSolid = new RasterizerState(Game.GraphicsDevice, renderStateDesc);

#5221676 XNA Game Choppyness

Posted by on 06 April 2015 - 12:59 PM

I don't remember if this applies to XNA, but when I get a sudden, massive drop in framerate it's because I did something wrong like lining up buffers wrong and I'm generating too many DX error messages for the system to handle. Check your debug output.

#5214746 Indirect references in a compute shader

Posted by on 05 March 2015 - 09:29 AM

Hi guys,


I'm trying to make a waterfall particle system for a large hexagonal game board, and I've seen some impressive examples of systems using the compute shader for particle generation and update. This will be my first compute shader algorithm however, and my needs are more complex than available samples.


First let me explain the problem area and the constraints I'm dealing with:


1.)I'm making a large map out of map chunks arranged in a 2D grid. Each map chunk can have many waterfalls or few waterfalls and most will have even no waterfalls at all.


2.)A single waterfall is represented by a line segment that spawns particles, and has no connection to any other waterfall.


3.)I only want to process particles in chunks that are close to the camera. As the camera moves the chosen chunks will change.


If I create fixed length buffers per chunk of this information, I will be wasting a ton of video memory because I might need to store a lot of info per chunk but in most cases very little or none. The problem then is that variable length buffers don't lend themselves well to assigning threads in a compute shader and they don't preserve the grid organization of the overall map.


So I need a scheme that allows me to organize references to variable length data in a grid pattern. I have an idea of how it might be possible, but it's going to require a lot of ugly, error prone math. I plan to dump all the waterfalls in the world into a ByteAdressBuffer and then use another fixed width structured buffer grid with each cell containing the byte offset and structure length and count of the appropriate data for a chunks worth of waterfalls.


So for each thread/particle, I would randomly choose a grid chunk within the appropriate range of the camera, then randomly choose a waterfall from the byte offset and struct count, then load in the waterfall struct with combinations of Load4, Load2 etc.(I guess you need explicit type casting in the hlsl code?) then randomly choose a point on the waterfall for the particle. Yuck!


Is there a cleaner way to achieve this kind of indirection in a compute shader, or is this the only way? Debugging this will be hard for me because I'm still on Windows 7 and VS Express.


EDIT: It occurs to me that since each waterfall uses the same structure, I could just use a structured buffer instead of a byte address buffer and put indices in the grid instead of byte offsets. Hey, I helped myself! Somebody give me an upvote.

#5190413 Questions about billboards

Posted by on 31 October 2014 - 10:15 AM

You know, its funny but it almost seems like with these indices coming in, using traditional vertex and instance buffers is obsolete. With this you can access neighbor information with some index math.

#5165286 Vertexbuffer - huge lag.

Posted by on 07 July 2014 - 10:24 AM

Are you setting things up to get debug warnings? When I use a debug device in DX11 (I don't remember how that works in DX9) and I do something not completely legit, my framerate plummets from all the reporting of warnings every frame.

#5163473 Ugliness on different hardware (solved)

Posted by on 28 June 2014 - 11:32 AM

That's it! Thanks for catching that!


I now still have problems with my rivers. I'm going to check real quick for some similar thing that might be going on there.


EDIT: Yep! I did an if(interpvalue == 1.0f) which you can't do and I know that, grrr.


Thanks everyone for taking the time to help me.

#5140105 DirectX 12 Announced

Posted by on 18 March 2014 - 01:56 PM



I only just got used to DX11 from DX9. It was so painful. Progress... must... stop!

#5131531 Dumbest question in the history of this forum(solved)

Posted by on 15 February 2014 - 07:28 AM

So, I decided to check out the new VS Express 2013 for windows, which required me to upgrade to Windows 8.1. I installed VS, created a new app from the DirectX template and debugged it to see the spinning cube.


Now it's the next day, and my question is, how do I start Visual Studio? It's not on my start page. Doing a search for VS Express brings up web pages. Do I have to hunt for the .exe in Windows Explorer? I've been a hobbyist Windows programmer for 25 years, but... I no longer know how to use my computer...


I haven't had this problem since I was 13 years old using a Commodore 64. I am very sorry.

#5111958 Displacement Mapping Gone Wrong (solved)

Posted by on 25 November 2013 - 03:33 PM

Ok, I've got this issue solved. I have the river sizes for each edge as part of the input for the vertex shader. Then in the hull shader patch constant function I determine the texture to choose and also if the texture should be flipped, and then in the domain shader I interpolate the coordinates for sampling the (u,0.0f) row of the texture which represents the river crossing.


Another issue is of course getting the right mip level at the patch corners, I cheated on this and simply used a zero value which is correct for this particular scheme only.

#5111279 Displacement Mapping Gone Wrong (solved)

Posted by on 22 November 2013 - 08:51 AM

I think I have the issue nailed down. I just have to fix it in a way that is not overly complicated in the shader and not too memory hogging overall. I want to keep my instance data small so I can build huge, huge maps.


Here is the issue with displacement mapping when your patch is designed to take a whole texture. Generally when we design tiling textures, we design them so that the edges are adjacent to the other edge. For example, the left edge is designed to flow seamlessly into the right edge for a tiling texture. Surface patches however, lie on top of each other at the edge, NOT adjacent to one another! This problem would exist even with square patches in my case.


No matter what kind of texture you use, even a high precision one, it is vital that shared patch edges sample the same exact data. Close is not good enough in this case, as the hardware seems to like to accentuate these cracks and even from far away they look like blinking Christmas tree lights.


The fact that I'm using square textures on a triangle patch complicates things, but there is one thing that is in my favor. All of the complex river interactions happen on the interior of the textures. At the patch edges, the only thing that ever happens is that one of three river sizes or none will cross there, and also they might be flipped. So I could sample either one of four 1D textures there or even use certain of my simpler textures at uv = (u, 0). I just have to devise a scheme for the shader to know what river size is needed and whether its coordinate should be inverted.


EDIT: I should add that these issues wouldn't exist if your texture border weren't co-mingling with your patch border. I could layer a rocky texture over the whole terrain without cracking. This only comes up if you are trying to build large textures out of pieces made to fit together at patch borders.



#5110810 Normal mapping issues (solved)

Posted by on 20 November 2013 - 12:36 PM

Ok, so I figured it out. Not only do I have to transpose the cotangent frame, but I also had two texture arrays, one for the height map and one for the normal map, and had also failed to specify which register they should go in. I decided to use my normal texture as a color texture to see what it would look like, and was shocked to see my height map instead! Using the conditional statement in the pixel shader worked sortof because it somehow forced the compiler to use the right texture. Setting the t registers to their appropriate slots fixed most of my problems, as I was sampling the wrong texture.


The only problem I have left is that using that conditional statement, which I suppose I don't really need, still looks bad on my nVidia gpu.



If anybody knows what automatic process is mucking this up, I would love to hear about it. In any case, it appears that my normal mapping code is correct now.

#5089642 Barycentric puzzle

Posted by on 27 August 2013 - 05:09 PM

Ok, here is a screenshot of some of the new developments. The most difficult part of this by FAR was drawing text. I did everything I could think of to avoid dx 11.1, but everything else had some reason why I couldn't use it. Anyway its working now. A cool thing I added was the ability to pick a hex with the mouse hover! (see the little green hex cursor) That made debugging the river system a lot easier, because if I saw a problem I could know which hex it was within a sea of hexes, and also print hex specific debug info on the selected hex. It works very well too, in an oblique view I can select a hex that is miles and miles (or whatever distance units you prefer) away.


The river system supports 3 sizes of river and currently just runs from the watersheds to the tiles that have no outlet. Right now, I'm just painting the rivers blue to make sure it's working, but later I will use these textures to make displacement and normal maps, and also possibly flow maps so that I can make the water surface flow down the river.


So the reason I needed to figure out this varonoi scheme is because now that I have rivers mostly working, I need to throw in the ocean and lakes. For now, I just need to paint them blue like the rivers to make sure it all works in a system, then I will start making it fancy.