It has been a few weeks since the last entry on optimising Darwinia+ on the Xbox 360. Most of that time has been spent hunting down any possible areas to speed up the code base and basically shaving as many cycles as I can from the frame time in order to get above the threshold of 30 frames per second. It’s been a tough time but the speed-freak inside me loved every minute of it.

There are many ways that Darwinia+ can be optimised but one of the most obvious is to make use of the three cores that the Xbox 360 has, currently the game is just using one ofthem.

Rather than go gung-ho and turn everything you can find into a thread on a different core I sat down to look at the areas of the game for something that could be easily broken onto a separate thread without major impact (and therefore less risk) and would reap the most benefits.

It may not seem like it but Darwinia+ has hundreds of sound effect files. There are many variations of each type of effect so that when you are listening to the game playing you get a broad range of sound rather than the same old sound playing over and over again.

As a consequence of this we can’t store all of the sounds in memory at the same time so we employ a caching system that reads in the samples, decodes them from OGG to native format ready to be played. As it turned out the actual act of decoding from OGG was appearing quite high in each of the PIX trace runs. This became my top target for breaking out into a thread because it satisfied the criteria of least risk and highest reward.

Thankfully the sound system was quite well designed and it took less than two hours to get the sample decoder working in its own thread on another core and much to my surprise it worked first time.

Of course refinements were added over the next couple of days once numerous tests were done to make sure it didn’t kill thegame. After running PIX on the outcome it became clear that this one small act that took two hours to complete had a massive impact on the speed of the game and we were much closer to the 30fps target.

As well as tackling potential speed bottlenecks using multi-core techniques a lot of analysis has been done on each of the games sub-systems with each area eliminated one by one. This is a very laborious task and it’s very easy to fall into a paranoid state where you are absolutely convinced that an engineer deliberately wrote the code just to make your life hell.

Of course the reality is that the next generation of coders being pumped out of university don’t appear to ever have the need or inclination to look at what the compiler produces or consider the actual impact on the CPU that a small innocent looking piece of C++ has. I was shocked to learn that at least one of our engineers had never done any assembly language – probably not needed in a Java dominated computer science course.

This brings us neatly to the education side of optimisation work. It’s fine to speed up the game but that is useless if all that is going to happen is your engineers will find evenmore imaginative ways to make it slow again – albeit not on purpose but it will happen.

So, as a know-it-all speed freak part of the job spec is to try and educate the masses into how not to undo all of your hard work. This is made even more fun by the various shades of ‘glazed over’ that each of your engineers can muster when you start to explain the intricacies of cache lines and why they should re-order the member variables of a class into most used and least used.

You have to keep trying though because the alternative is yet another round of the same thing on the next game.