Categories: Uncategorized Posted on December 24th, 2009 by Bino
Rewrote and reworked the prototype code for use on the iPhone. My initial implementation could only handle roughly 20 bullets at < 20 frames per second. What made things worse, there was no collision detection being done! So there was no chance of building a game with things in this state. I know the iPhone isn’t a work horse like my PC but surely it’s capable of more than this!
I initially thought the culprit was BulletML. However my basic profiling didn’t produce evidence to support this. Further profiling using instruments showed unusually long spikes in drawing. It then dawned on me a really obvious bottleneck…
I originally setup the prototype to store a bullet per scenegraph node. With this setup, each bullet sends a new draw command to OpenGl. Clearly what was needed was to batch the bullet drawing.
After reworking the code to accommodate this, the prototype was handling complex bullet scripts with a cache of 300 bullets quite easily. I’m sure there are further optimizations to be had by delving into BulletML… But as it stands that’s going to be a time sink.
There are a few posts on the Internet saying that BulletML is too slow to be used on the iPhone. I disagree. Clearly you’re still limited compared to a PC but it’s possible to get a good amount of bullets at a decent frame rate. Additionally, you’re working on a small screen so you don’t really need 3000 bullets?
My next task was to incorporate the Bullet physics engine. I planned on moving the bullets by applying impulses. However this took a fair bit of CPU processing and the final results seemed like a souless version of BulletML. It felt wrong and looked wrong. So I opted to use the bullets as kinematic objects thus letting BulletML control the movement entirely. In hindsight, this makes even more sense as the bullet movement patterns are only calculated once.
Still a fair bit to do. No doubt I’ll run into a few more perf issues. Looking forward to it!
Bino
