Skip to content

Symbian, 2D games and Qt Optimization Flags

After two and a half years building rich UIs on top of QGraphicsView and trying every kind of exotic flags or approaches to get better performance results on symbian, I’ve decided to publish some of them which can be useful to game programmers.

With a little help of Ademar, we’ve selected a good use case: a bouncing game.

The game

10 balls image of chainreaction game

This game is simple: there are some balls running on the screen, and if you press one of them it will explode, and if a red ball touches a exploded ball, it will explode too. However the game logic is not important here. Lets list some of the characteristics of this game from a developer’s point of view:

  • Static background.
  • Balls can be implemented as GraphicsItems.
  • Red balls are always moving.
  • Non-exploded ball doesn’t collide.
  • List of elements can grow fast.
  • The items are scattered on the screen
The comments bellow are only valid for the characteristics of a game defined above.

The flags

The flags I want to comment on this post are:

The results

* Those tests were performed on a Nokia 5800, type RM-356, with V51.0.006 firmware and Qt 4.6.3.
** The Y axis is measuring FPS: the higher, the better.

10 elements on the screen

First of all, I’ve tried the four ViewportUpdate methods, with 10 items on the screen, and the MinimalViewportUpdate and the SmartViewportUpdate gave me the highest FPS( 34 and 33.5) . Qt documentation shows NoIndex as the best option for dynamic scenes… well, the difference is small for few items, but it’s true =)

So, for the other tests, lets use the NoIndex flag.

What about optimization flags?

I took two results from the latest test (SmartViewportUpdate and BoundingRectViewportUpdate) and ran it again with two optimizationFlags: QGraphicsView::DontSavePainterState and QGraphicsView::DontAdjustForAntialiasing. So, optimizations flags brings us a little bit of improvement when we can control precisely how the items will be drawn.

20 elements

30 elements

40 elements

Lessons Learned

It’s important to select the correct ViewportUpdate method for your kind of scene. It can make the difference.

If there is a lot of dynamic elements, and if they are scattered throughout the scene, it’s cheaper to paint the whole screen (or, at least, the bounding rect) instead of trying to determinate the affected area.

To be honest I was expecting a better result from FullViewportUpdate, but I believe it would be better than BoundingRect if we use non-static background.

What if?

What if I use only one graphicsItem to paint all the balls? What if a ball was not an item but an object with a render method?

I got a little bit surprised, it wasn’t the result I was expecting – it’s worst. It only gets to be better when I put more than 60 items on the screen.

Will I throw the code in the garbage can?

No! As the result of the tests and with a creative help of Nara – INdT designer – I’m releasing a playable alpha version of this game, called by Chubba-Lubba. It’s not finished, since it’s still missing the icon, sounds and scores features, but it’s testable =)

Symbian package here!