Note: this article isn’t a benchmark. This article investigates GL-ES rendering performance in a running game prototype (with game logic running, not just GL rendering).

Today I’ve tested rendering performance with a simple character – ‘hit-man’ (230 vertices, 206 faces):

  • idle animation
  • walk cycle
  • hit animation

I use indexed faces (GLDrawElements) without VBOs (glVertexPointer). I’m not sure about using VBOs for actors because I interpolate animation frames on the fly – if I want to use VBOs, I’ll have to worry about how many mesh duplicates I can buffer, when to release them and so forth…

I animated a 100 actors this way, and it wasn’t fast – not hopelessly crawling like when I added game logic for the same 100 actors – just slow. So I did the obvious – added a boundary check to render only actors visible on-screen. That brought back an acceptable frame rate right away, without the need for further optimizations. The frame rate is still about OK with 20 actors on-screen.

This came as a surprise since my terrain rendering (no VBOs either) generates the highest overhead in my iPhone app. Here’s a quick breakdown of processor usage (rendering related only):

  • 40% – GLDrawElements for terrain (300 tiles, about 18400 faces)
  • 20% – Frame interpolation
  • 3.5% – GLDrawElements for actors (20-25 on-screen, about 4000-5000 faces )
  • (drawing props and doing other things)

Admittedly, my tiles are heavy. But frankly, it doesn’t add up – Getting 4 times more actors on-screen would just bring up drawing cost to 15%(1) (never mind frame interpolation), so still much less than tile rendering on the side of GL performance.

An experiment

I had a feeling that drawing large triangles took much longer than drawing small ones – so I iterated with basic square tiles (2 faces, 4 vertices) – here’s the result:

  • 9% – GLDrawElements for terrain (300 tiles, about 18400 faces)
  • 34% – Frame interpolation
  • 7.6% – GLDrawElements for actors (20-25 on-screen, about 4000-5000 faces )
  • (drawing props and doing other things)

In this configuration the game runs all nice and smooth – it’s not just that the tiles had many faces – faces for a single tile covered each other as well.

Conclusion

Rendering more pixels slows down rendering more than rendering more faces – With an isometric view, simple tiles and detailed characters can be a good combination.

(1) The way I evaluate this is so so – multiplying percentages this way isn’t maths