Open GL Rendering (best practice)

[StoneWolfe]

Hi all,

I am developing a 2D game for the iPhone (thanks Mike for getting me started with your excellent tutorials).

The game displays numerous sprites from the same sprite sheet on screen at any one time. To improve the efficiency of this I re-worked some of Mike's examples to create a render manager that batched up all the sprites being rendered from one texture and submit all vertex and texture data in one glDrawElements() call.

As I have been improving the look of the game I now want to rotate the sprites based on their movement direction (i.e. my sprite are drawn facing up the screen, if the sprite is moving to the right of the screen then I want to rotate the sprite by 90 degrees so that it is facing right). If I were drawing each sprite as a individual call to glDrawElements() then I could change the OpenGL rotation state using glRotatef() to handle this but as I am drawing all the sprites as a batch I am having to calculate the vertex rotation myself in code (which means it's all being done on the CPU).

Now I'm worried that the performance improvement from making a single glDrawElements() call likely to be negated by the cost of performing the sprite rotation on the CPU rather than the GPU?

In a nutshell:
1) Should I leave things as they are
2) Should I switch back to drawing the sprites individually
3) Is there some other mechanism I could use to still do the rotation calcs on the GPU while still batch drawing the sprites...

Thanks in advance for any insights...

Paul

[Sumaleth]

Unless you're rotating thousands of quads at 60Hz while running a physics simulation, you don't need to worry about doing rotations on the CPU.

The threshold is probably a lot lower if you're trying to support the iPhone1, but with the latest iPhones you can do a lot on CPU before you'll have to think about optimization.

Rowan.

[StoneWolfe]

Thanks for the information Rowan - I'll leave it as it is for now and see how the game performs when it's finished.

There's no physics and there'll be a maximum of a few hundred sprites on the screen at once of which only about 10-20% of them will need any rotation code. So it sounds like I should be OK.

[A Person]

The CPU should be able to handle a small number of sprites at 60 fps no problem but if you do find that things a little slow you can use OpenGL ES 2.0 shaders to have the rotation done on the GPU and sent back although you generally don't want to have the CPU and GPU chattering all the time so that would be a whole new issue itself.

[WhatsOurVectorVictor]

1) Should I leave things as they are

Assuming things are still running smoothly then this is a sensible approach to take (good to see you opted for it!) - no need to worry about optimisation for the time being.
However, when the time comes, the answer can only be that It Depends. You need to know for certain that the rotation is a bottleneck in your implementation before you can begin improving anything, and there may be bigger problems you should look at first. You'll need to break out the profiling tools to find out.

2) Should I switch back to drawing the sprites individually

Probably not. Typically you want to send as much data to the GPU as you can in as few OpenGL calls / state changes as possible. Batching multiple sprites into a single vertex array will be more efficient than having to duplicate draw calls for individual sprites.

3) Is there some other mechanism I could use to still do the rotation calcs on the GPU while still batch drawing the sprites...

As A Person says, you can use ES 2.0 & shaders to rotate your objects. Specifically you can pass custom parameters - including rotation data - to the shader as part of the vertex array, and perform the transformations in the vertex shader.

However I don't recommend copying data from the GPU back to the CPU, at least in this case, as it's quite an expensive operation & there are often better alternatives. I'm not really sure what you'd use the returned data for either - an abstract representation of an angle (i.e. a vector of Euler angles, quaternions, whatever) is going to be more useful to other CPU-side code than raw vertex data in most cases.

[mike]

I'm late in the game on this thread but the guys have given you anything I would have said )

In my book I've done exactly what you are doing. I have a render manager that batches up sprites to be drawn and then draws them in texture order so it renders all sprites using the same texture first before switching textures and then drawing sprites that use this new texture.

All transformation, translation and scaling calculations are done on the CPU and unless you have a mad number of sprites, you shouldn't see the CPU struggle too much. If you went back to drawing each sprite individually then you would see a HUGE drop in performance.

Moving those calculations to the GPU which can do tens of billions of operations per second is a good step forward and is made SOO much easier now with the introduction of GLKit in iOS 5. For the moment though, if your not seeing a performance problem with your current approach stick with it

Mike