Hey all, I'm in the midst of creating my 2D engine. I've decided to go with a fairly large vertex cache and filling that up instead of a bunch of independent vertex buffers. This let's me batch triangles in huge doses and is (excluding this) working quite nicely. This is what happens every render update: Sort sprites (Layer then Y then Texture) for every texture: lock vertex buffer fill in all sprite data unlock draw (position in cache, number of polygons) I added some timing code today and found out I'm running at a whopping 20 frames per second. I was shocked because I was only using 2 textures, so I shouldn't of been being hit by the fairly expensive lock calls. I downloaded a profiler and ran it. I found out that every single VertexBuffer.Lock() call is allocating up to 36KB of memory every frame... My allocation time-chart spends more time allocating this memory then rendering the frame itself so this has to be the problem. I'm using Managed DirectX and my lock call looks like this: vbData = (Direct3D.CustomVertex.PositionColoredTextured[])_vertices.Lock(0, 0); I know that's locking the whole buffer and I will fix that later. Can anyone make any recommendations on what I can do? Surely the Sprite interface uses a similar locking system to achieve its goals.

Locking is generally slow as all the data goes over the GPU-system bus. You should at all times avoid locking during a render loop unless it cannot be done any other way. Surely the sprite interface does not do this but uses billboarding instead.

Why must your buffer be locked? Can the data be static? Can it be computed by transforming static data only? Etc.

Greetz,

Illco

I don't see why you access the vertex buffer at all. The way I envision it you place the necessary sprites into the buffer during initialization, then only allocate an index buffer to determine which sprites get drawn.

If the sprites additionally need to move about, then you can use the world-transform while rendering each of those sprites.

Thanks everyone for the help, changing the locking flags was the main solution. I also had a bottleneck within the loop itself (note: logging debug information to a file every rendering frame is not efficient).

The batching solution is on-par with the sprite interface and I have the full control I'm seeking.

Thanks again.