Par thy Android - A short followup on "60 FPS to 500"

Last week we published a blog post briefly outlining several steps of optimization of a Haskell game. In the article, the last two steps, which referred to parallelism and concurrency respectively, were inverted, making it sound like the Android version was using the parallel library. This was not the case: parallelism was the last change to be introduced chronologically, and we had never tried that on Android.

There was also a mistake in the code that printed the FPS for the renderer (hard coded number of frames, leading to an error when it was changed from ’every 10 frames’ to ’every 20 frames’). All the figures for the renderer in the last post should be x2 (it will be fixed in the other article later on, and this remark removed.)

It turns out that, with parallel enabled, there is a substantial performance boost, reaching about 60 FPS in average for the renderer and the same number for the physics (between 80% and 100% faster than without parallel), making the game run at the performance we need for now. The tests are all being executed on a Galaxy Tab 2 with the stock OS. The game is printing output stats to the logcat (using a custom FFI function).

For those who might be thinking, after reading last week’s post, that the performance was too low on Android, I hope this comes as good news: by using par, and with just a few lines of code (Page 21 of Parallel and Concurrent Programming in Haskell), the speed nearly duplicates. We will still carry out other improvements anyway but, taking into account that all the optimisations were quite simple and we did not design the game to run fast but to be easy to read and understand, we consider this a success.

Next steps

This does not mark the end, but the beginning. Maybe not all games are possible, but now some are. It’s a foot in the door, nothing more. There’s still a lot of hard work to do. But this gives us all the opportunity to get into a market mainly dominated by a handful of languages, a chance to prove that FP has something useful to contribute to every user.

There are plans to apply the same changes to the opensource Haskanoid game (which, although using SDL1.2 instead of SDL2, suffers from similar issues), in the form of a step-by-step tutorial, so that people find it easier to evaluate each claim and don’t need to take our word for it. This may also be a good opportunity to scrutinize the testing procedure and provide better, detailed benchmarks, which at the present time are slightly hard to produce because each game input, and thus run, is unique.

We are bringing Haskell to mobile platforms. We are currently preparing out first Android game written in Haskell, and that’s why we need all your help. Please, let others know about what we are doing via Twitter and Facebook, so that they can be ready to try the game when it comes out. To all those who subscribed, followed, liked, sent supporting emails and donated via flattr, a very sincere, wholeheartedly thank you.