How to improve batching performance

Question

I am developing a sprite based 2D game for mobile platform(s) and I'm using OpenGL (well, actually Irrlicht) to render graphics. First I implemented sprite rendering in a simple way: every game object is rendered as a quad with its own GPU draw call, meaning that if I had 200 game objects, I made 200 draw calls per frame. Of course this was a bad choice and my game was completely CPU bound because there is a little CPU overhead assosiacted in every GPU draw call. GPU stayed idle most of the time.

Now, I thought I could improve performance by collecting objects into large batches and rendering these batches with only a few draw calls. I implemented batching (so that every game object sharing the same texture is rendered in same batch) and thought that my problems are gone... only to find out that my frame rate was even lower than before.

Why? Well, I have 200 (or more) game objects, and they are updated 60 times per second. Every frame I have to recalculate new position (translation and rotation) for vertices in CPU (GPU on mobile platforms does not support instancing so I can't do it there), and doing this calculation 48000 per second (200*60*4 since every sprite has 4 vertices) simply seems to be too slow.

What I could do to improve performance? All game objects are moving/rotating (almost) every frame so I really have to recalculate vertex positions. Only optimization that I could think of is a look-up table for rotations so that I wouldn't have to calculate them. Would point sprites help? Any nasty hacks? Anything else?

Thanks.

Answer 1

Did you use my port of irrlicht for android ? For 2d sprites on Android and iphone, i use the same tricks as you: batching. I try many solutions in OpenGL ES 1.x and 2.x:

• sort by z (parallax) and by texture, do the transformations on the CPU and call glDrawArrays or glDrawElements (fastest way). Use one big texture if you can.
• same trick with VBO, not faster because for each frame you refresh all informations. It can be useful for statics sprites.
• use OpenGL ES 2.x and use Vertex shader to compute positions (slower)
• use PointSprites (no solution if it is not a square and too many transparent pixels kill fillrate)
• use gldrawtexoes extension...
• use a drawcall for each sprite (slowest method)

So as you, all transformations are done by the CPU for OGLES 1.x or OGLES 2.x. If you have neon instructions, you can use them to speed your computations.

Ps: on iphone or android devices, i'm not CPU limited but fill rate limited. So it is very important to limit overdraw.

Answer 2

I would recommend having a VBO, with each vertex containing the position/rotation of each rendered object and batching based on texture like you're doing. I'm not very familiar with ogl ES, so i'm not sure which version of glsl it supports, but you might even be able to batch based on a set of textures, and store which of the 4 or so textures you are passing in you'd be using inside of the vertex. Point sprites would definitely improve you're performance because it would cut down the amount of data you are sending over drastically, and batching should never decrease performance if you are doing it correctly. Also, you could improve performance a bit by computing rotation on the shader and only passing in an int/float value into the params or inside the vertex itself. (params would be faster, just create an array for each batch and have an index into that array stored inside the vertex itself)

Answer 3

You mention mobile platforms which do not have instancing. But, you still do have vertex shaders, don't you?

In that case, you can still do pseudo instancing, which is very fast too. Make a VBO (GL_STATIC_DRAW) with the corner points (relative to the center point of the sprite, e.g. -1/-1, 1/-1, 1/1, -1/1) and any texture coordinates you need, in it.
Then set one of the generic vertex attributes for every draw call to the centerpoint of the sprite, and draw the two triangles with the buffer bound. Inside the vertex shader, read the generic vertex attribute and add the vertex's coordinates.

That will save you blocking on a data transfer for every sprite and should be much faster. The actual number of draw calls is not so terribly important, the blocking/stalling in between is.

Answer 4

The problem resides in the amount of data you are sending to the GPU each frame. Just create a VBO for each batch and populate it once, then apply the corresponding transformation matrices (via glMultMatrix, or a shader if you are using ES 2.0) when drawing the batches.