   Fast 3d sprites
  I'm making my second game. It's still 2d but based on Direct3d9.0c. In the past my sprites were quads rendered using DrawPrimitiveUP. What can I do to substantially speed up rendering assuming that I wan't to use only fixed pipeline dx features? Also, I need per frame access to vertex data, so that I can apply simple transformations in screen space, like rotations.   
  If you're doing a 2D game chances are you've got a static background that you scroll around and "Dynamic" objects that move or change within the frame of this background. Use static vertex buffers for all the static stuff, sort all your data to draw so you change texture and shader data as little as possible (as this is very slow) use a transform to scroll the BG. Create dynamic vertex buffers for objects that are built up every frame. Fill up vertex buffers with like data eg: textures, shaders, etc. Do tests to make sure you're send as little off screen data as possible to be drawn.;  Dynamic vertex buffer and static index buffer, drawing indexed triangle lists.Using an index buffer enables the GPU vertex cache, and means you can transfer less vertices (4 per sprite instead of 6, assuming you're using quads for sprites), and a dynamic vertex buffer should be slightly more efficient than using DrawPrimitiveUP (Since it tells D3D it can access that data whenever it likes after the Unlock()).Internally, D3D just keeps a dynamic vertex buffer around for using with DrawPrimitiveUP, and it copies the data you pass into that VB (Although it's presumably not a "standard" VB).If possible, do transformations yourself on the CPU if you're not rotating hundreds of sprites, and put several textures onto one texture atlas. Then you can probably render all your sprites in one DrawIndexedPrimitive call. Remember that Draw[Indexed]Primitive[UP]() is the main bottleneck, and you don't want to cal lthat more than a few hundred times per frame. Larger batches are better.   ;Quote:Original post by Evil SteveInternally, D3D just keeps a dynamic vertex buffer around for using with DrawPrimitiveUP, and it copies the data you pass into that VB (Although it's presumably not a "standard" VB).DrawPrimitiveUP copies verts directly into the command buffer (where all the draw and render state commands go). With small batches it could be slightly more efficient than standard VBs because it doesn't need to do any synchronization (no "locking"). With larger batches it's less efficient because of extra memcpy and because the command buffer is not the best place for fast vertex fetching.EDIT: I'm not sure if the command buffer method is implemented in all drivers. At least it works that way on the Xbox 360 (it's mentioned in some slides on the Microsoft site). Better assume that DrawPrimitiveUP is implemented the slow way![Edited by - deathkrush on September 5, 2007 2:01:45 AM];  In my last sprite system I used D3DPT_TRIANGLESTRIP for rendering. I didn't have an explicit index buffer, just 4 transformed vertices. I did rotations on cpu.If I want to use dynamic vertex buffers I will have to put all my cells into one texture. If calling DPUP moves vertices to an internal vertex buffer, then what do  I gain by using dynamic buffer explicitly? If I draw 1000 sprites per frame using DPUP, with the same texture (without texture switching) is it significanlty slower than an explicit dynamic vertex buffer?Thx for help!   