TIGSource Forums

I just tested my spritebatch feature without VBO's for the first time and discovered that there's no noticeable performance difference.   5000 sprites goes at the same 60fps either way.  And my machine is 3.3ghz with a Radeon 5750.

Is that about right?  

(Btw I'm using shorts for vertex coords.  I read that floats are always best for video cards ... but the thing is, either way, they have to be converted from integers because of how my program is set up, so I thought if that's so then the driver will probably do the best job.)

Maybe I'll start only seeing performance improvements with static spritebatches ... currently updating one each frame.

Is it maybe running at exactly 60fps in both cases because you're vsynced?

i just discovered i'm totally CPU bound beyond belief.  i did some optimization and got 8000 a frame now.

well i benchmarked the function that updates the vertex buffer, and shockingly it takes more time with vbo....  it's ~16000 microseconds vs ~19000 !

I wouldn't be surprised if a VBO is one of these things where modifying it slower than vertex arrays or immediate mode, but having static batches is much faster than resending the vertex info every frame by whatever means.

So yeah, echoing your thoughts.

yeah it is probably as fast as it is going to get.

Not really related to your issue, but I found VBOs in general to be slower than vertex arrays/immediate mode on computers with shared graphics memory. Just something to bear in mind depending on your intended target machines.

I use display lists.  They're an old system, but they're generally as fast as anything else for batching static geometry and they're quite well-supported even on ancient hardware.

I guess the disadvantage is they have no equivalent (?) in DirectX's paradigm, but who the hell cares about that?

One downside to display lists is they go away in OpenGL ES :(

Depends on the system, but I've found interleaving VBO's can have a big speedup.  This was the case for iPhone and my Mac, although may not be on other systems.

Provided you aren't changing the VBO data every update, they should most definitely be faster than any other method of rendering geometry.

What type of hardware are you targeting? I know geometry shaders aren't commonly supported yet, but perhaps you should look into using them to expand single points into quads for batching sprites together. Could reduce the amount of data you send to the card by a factor of up to 4.

yeah, i confirmed vbo's to be extremely fast when the array is uploaded only once at init.

i'm targeting opengl 2.1 supporting cards at the moment.

i have an idea to write a vertex shader that takes a pre-allocated vbo and a uniform array of some kind that would generate sprites using u, v, x, y, rotation, scale etc as input.  the obvious downside is that the vbo would contain nothing but zeros, so it wastes memory.

geometry shaders have a limit to the number of vertices they can generate that differs from card-to-card so i shy away from that for now.  (also, indeed it ISN'T currently supported, right?)

anyone know a workaround to the wasted vbo?

DX11 has command buffers which can be used in a similar manner to display lists and are generally more flexible and more closely related to the way hardware\drivers work. But you're right that no one on TIGSource cares about DirectX.