Moviestorm performance

I've recently been examining performance, so maybe it'll help to have an understanding of why Moviestorm is the way it is.

MS is render-bound at the moment. It spends more time drawing than computing other stuff. I'd kind of expect this. I think one of the big differences between MS and a game is that a game can fine-tune the resources it needs for a level offline. For example, it knows ahead of time all the textures it will ever need, and can optimally pack them into texture pages that minimise the transfer of bulk pixel data between system memory and the GPU. In MS, we can't do this because a user can have any number of different objects in any scene potentially containing their own textures. Or as another example, shaders in MS need to be compiled on-the-fly depending on what the precise lighting and material characteristics of the set are, whereas a game can simply pre-compile them all and load them up en masse. So because MS is an "open" system that can't make assumptions about the data that'll be thrown at it, there is a compromise in performance (conversely, games perform fast because they severely restrict the things that can be changed).

I don't think we're bound by poly count. We could probably raise or lower them by some moderate percentage and not see better frame rates. We submit vertices to the GPU through the DMA channels that OpenGL provides us and my impression is that we pack around 10,000 verts into a buffer that could contain 16,000. Coalescing the buffers won't necessarily result in a 60% speed gain because of the need to pack and unpack the streams. Besides I think it's good to have headroom for future expansion - something games are usually less concerned about.

That said, we're well aware of the things we can do to boost performance. On the CPU side we need to get our skeletons working smoothly. We started off using the CAL3D animation package, and I have to say that it has features that both sap performance and make it awkward to work with. Given time and/or an infinite number of helper monkeys I think these things would be done in a jiffy; whilst we're on the hunt for them primates, we're always looking to improve things. Just this week I have implemented a number of speeds-ups in the skeleton code, for example. We're also thinking very hard indeed about how to resolve some of the lumpiness in MS's performance whilst managing the potentially vast open data sets of AddOns.

On the GPU side, that's a bit harder. We need to run a performance anaylser on what the video cards are doing, and that's a specialist skill. Finding someone who can do that professionally has proven to be either tricky (in reality there are few with the skills) or prohibitively expensive. We'd love to get the help of the hardware vendors, but in reality we're probably a little on the small side for them to take notice as of yet. As we grow, I expect that to change. And when it does, chances are we'll be able to quadruple the body counts and perform much more sophisticated lighting calculations, and all the things that games are doing now (though it's worth stressing that not all cards will support such prettiness and we have to keep all our customers happy). In the meantime, it's fair to say that MS performs comparably with competitors such as Antics, which didn't even have lighting and shadows till way late in the game, which was shader-less (their faux shaders simply controlled the OpenGL fixed-function pipeline) and so couldn't do things such as depth-of-field, particle volume renderers, normal maps, depth sprites, and some of the things potentially coming (no promises mind!) such as skylight absorbtion, bloom, and maybe even the deferred rendering technology seen in games such as Killzone.

MS is a rapidly evolving piece of software. We've not been afraid to tear down large chunks of legacy code and replace it with leaner, meaner, prettier - or more robust - variants. This will continue as long as there's breath in us! Though at some point, we're sure things will stabilise a bit, and at that time - bearing in mind the advice of Mr Computer Science himself, Professor Donald Knuth's, advice "never optimise early" - we can start tuning the performance. It's worth saying though that a software engineer typically has a number of criteria the application should satisfy. For example:

* Performance (measured in frame rate)
* Responsiveness (does it do what I want when I want?)
* Stability (how well it performs over a spectrum of hardware)
* Robustness (how often serious problems occur)
* Scalability (how far can it be pushed)
* Extensibility (closed, or degree of openness)
* Security (can it be maliciously hacked?)
* Ease of use

These criteria are generally not independent, and different priorities will be put on them depending on the type of application as we realise they can't all be satisfied simultaneously. Games tend to emphasise the first two, whereas MS has a different set of weightings, and (say) an internet browser will differ to both. I think we've done pretty well thus far, and though of course I'd like to see more bigger faster prettier right here right now, the reality is that we have to wait a while. We're not like a game - we don't release and then forget (admittedly now game developers may release patches to fix their over-hurried engineering hacks and blunders); we promise continual, regular delivery, and improvement with every version. Not bad for a free app, eh?