and thank you cgrant. this is the reason i asked for the specification. as we appear to be seeing some devices that are behaving slightly different. we resolved it by raising the precision however we would like to know if it is an implementation error on the driver or our part.
•Minimize state changes and group the remaining state changes. How do you group state changes?
- for example... changing the alpha blending.
•Use static vertex buffers where possible. How do you know if it is static?
-i forget the flags but basically... can you write to it after it's created? then it isn't static
Use one large static vertex buffer per FVF for static objects, rather than one per object. What if each object has the same vertex property? Eg. all objects are 256 x 256 quads? reuse the same buffer?
- i create 2-3 pools. switch pools every frame. hopefully reduces lag to gpu
•If your application needs random access into the vertex buffer in AGP memory, choose a vertex format size that is a multiple of 32 bytes. Otherwise, select the smallest appropriate format. Random access as in needing to change vertexes at runtime?
- data = vb->lock(); data +13 = x; vb->unlock(); lock/unlock as minimally as possible. write to a locked buffer as minimially as possible.
one thing i noticed is you are doing 1 draw call per sprite. group sprites by texture to reduce draw calls. you may have 10k sprites but do you have 10k textures? maybe you have 10k sprites but they are on 2 textures. you don't need 10k draw calls. you can do it in 2.