Helpful Box2d Tweak For Extra Performance

Just a quick post to give a status and to share with others the results of a tweak I found that significantly increased performance on the iPhone 4 (our base device, though I’m increasingly wondering why…)

First of all, Dan and I have been crushing our remaining issues/bugs like mad men to meet our demo completion date. Our hero is a running, jumping, knifing, punching, head stomping mad man and the bad guys have very much to worry about. He’s even swinging on chains over pits. It’s pretty crazy what he’s able to do.

So we’re feeling pretty confident if maybe one or two days behind. Pretty awesome.

As for the tweak I discovered, I was profiling the game on my iPhone 4 to see what I could squeeze some extra performance out of and kept seeing that there was one method that was eating an inordinate amount of CPU time for what it should have been doing. See the image below.

Profiling. It still matters.

Profiling. It still matters.

What you’re seeing there is that a helper class that came with our LevelHelper tool has a method called update. This method then calls LHSprite‘s transformPosition method which then does a couple of things on its own, including updating the Box2d body’s position as well as the CCSprite‘s position.

But what was eating up so much of the CPU was the b2BroadPhase:UpdatePairs call. And I mean a lot.

Prior to the change I’m about to tell you about, this updating method took 21.8% of the total CPU time, and the entire function of LHPathNode is to animate a sprite along a path!

Fortunately, through some creative Googling that I normally leave to Dan, I was able to find this post on the Box2d forums in which it suggests to change b2Settings.h from:


#define b2_aabbExtension 0.1f

to


#define b2_aabbExtension 1.0f

According to the documentation this setting:

…is used to fatten AABBs in the dynamic tree. This allows proxies to move by a small amount without triggering a tree adjustment. This is in meters.

With our big crushers, seen up in the banner image (because this episode is badly written), moving up and down at a fairly quick clip, this was triggering a resort of the tree over and over again. I settled with a value of 0.5f and found that the CPU usage dropped by more than half to just over 8%.

I may up the number further but have a feeling that it will most likely have an effect on any raycasting Box2d tries so I’m trying to find the nice balance between performance and feature trade-off.

We’re not back at 60fps for the iPhone 4 yet (we’re hovering around 45fps) but this was the single biggest performance increase I was able to make by changing one line of code. Not bad for an evening’s worth of profiling.