Archived

This topic is now archived and is closed to further replies.

How index buffers help...

This topic is 5747 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

To those of you who posted in my last thread, I''m sorry for that, I''ve been very frustrated as of late. I''m sure you know how it goes, and I hope you simplathize. Anyway, to my question.... I''ve been coding my game with D3DXSprite for a while now, and I keep trying to get into my own sprite engine but I can''t really decide which way to go with it. If I do it, I wanna do it right. No I was gunna do use triangle strips to draw my quads, but I figured for 200 or so sprites a frame, the memory saved would not make up for all those added rendering calls. Then I thought about index buffers. But with those, from what I understand, you save speed because you manage the memory of the vertecies yourself, and you don''t have to lock them and all everytime you change them. You just have to lock the list of indecies (pointers). However, you loose memory because you have create the vertecies and the pointers to them. However, you also gain speed because you can send a nice packaged list of verticies to the renderer all at once. Now, which is really better, keeping mainly speed in mind. And also, if you use index buffers, then is there a way to create the vertexes in video memory (if the card can spare it)? Thanks everyone

Share this post


Link to post
Share on other sites
My lowly geforce 2 MX can supposedly render 20 million triangles a second. You may never get anywhere near that geometry rate in real life applications, but even at 1 million triangles a second, thats more than you would ever need for a 2D sprite game. 200 sprites per frame* 2 triangles per sprite * 60 frames per second = 24,000 triangles a second, or 0.12% of theoretical maximum geometry output.

Basically, your sprite class is not going to be limited by the geometry engine of the card. Its far more likely that you will hit the fill rate bottle neck before the geometry bottleneck. You could probably even get away with DrawPrimitiveUP and never notice a speed difference (Direct 3D batches small UP calls into a vertex buffer anyways). You should always worry about optimizing the parts of your program that matter, instead of wasting effort to come up with a more tedious and complicated solution for marginal speed increases.

That said... index buffers usually SAVE space, because it takes only 16bits (use 16 bit indices, not 32 bit, because many cards support only 16), and most meshes reuse the same vertices for multiple triangles. You even save some space on your quads by eliminating 2 duplicate corner vertices, but at 200 sprites * 2 bytes per index * 6 indices per quad = 3200 bytes, would you care if you didn't?

Here are some general performance tips: Most newer cards are fastest on triangle strips and indexed lists, so if speed is really a concern use these. Both the vertex buffer and index buffer can be on card if the drive supports it. See the documentation for all the flags you can specify. Avoid locks as much as possible by doing updates on a local copy in system ram and only locking to copy the updated results. Never do a read on an idex buffer or vertex buffer -- read from the local copy.

See the direct X articles section on developer.nvidia.com for tips on optimizing performance if you are interested.

[edited by - invective on March 23, 2002 2:51:44 AM]

Share this post


Link to post
Share on other sites