I have a lot of (~400 quads onscreen at the same time) textured, blended quads that need to be rendered. No z-buffering, no stencil, sorted and fine. I was just wondering, since none of them shares vertices, is there any reason to use DrawArrays over immediate mode? As they are moving, I can’t put them into a display list. Is there any kind of speed-up that can be done in passing the vertices to the card?
Hi,
The Vertex Buffer Object extension might help, but just 400 quads isn’t much. The binding of 400 textures might take more time than you think; I am using thousands of quads, and the time-consuming part is the uploading and conversion of the texture data, at the first frame displayed (when using lots of small textures; when there are just tens of textures, but 8x larger, it’s much faster).
Unfortunately, I can’t use VBO’s - my low-end specs don’t allow for them. So I’m going with display lists, then?
Thanks for your time, and merry christmas!
Unfortunately, I can’t use VBO’s - my low-end specs don’t allow for them.
VBO’s are designed to be implemented in vitually any implementation of OpenGL. As such, even such low-end machines like TNT2’s and so forth should (and, in the case of nVidia’s hardware, do) implement them. As long as the user has up-to-date drivers, then the user should have VBO support. Unless the hardware in question isn’t being supported anymore (3Dfx hardware), in which case you can’t even know if display lists are optimized.
Of course, you’re right. Don’t know what I was thinking. Thanks a lot!
Why don’t you use Display Lists and move them by the Modelview Matrix? Don’t know if that’s faster, but benchmark it.
Another idea is to us alaised point with ARB_point_sprite extension if it is possible.
have a lot of (~400 quads onscreen at the same time) textured, blended quads that need to be rendered.
400 quads, using 4 vertices with 4 position coordinates and 4 texture coordinates is trivial to compute, even for a really low end video card (or even on the CPU, if there’s no hardware T&L).
400 quads is nothing. You’re most likely not geometry limited (unless you need > 1000 fps).
You’re most likely fill-limited instead. Assuming each quad is 128x128 pixels, and that all textures are in a texture cache (not likely), then for 60 fps, you’ll need:
128x128 * 400 quads * 60 fps * 2 (blending) * 32-bpp ~= 3 GB/sec.
This is just for the pixel pushing. Unless you have a moderately recent video card with it’s own RAM, you will not be able to push so many pixels.
Now, if your quads are really 32x32, then you just need 186 MB/sec for pixels (double that if each quad needs it’s own texture with is not in cache).
That said, you won’t gain anything (or anything much) from using anything more fancy than immediate mode.
However, if you’re planning to have many more quads (> 5000), much more geometry, etc, then you might want to look into point sprites, as Corrail suggested, or ARB_vbo.
>You’re most likely not geometry limited
I don’t know where I left my brain… if anyone sees it, please mail me.
Of course, you’re right. I honestly lurched around trying to optimize my geometry submission, while my fill rate will go to hell.
Thanks for your time, this was a stupid post. Sorry.