Question

Can anybody spot what is wrong with the code below. It is supposed to average the frame interval (dt) for the previous TIME_STEPS number of frames.

I’m using Box2d and cocos2d, although I don’t think the cocos2d bit is very relevent.

-(void) update: (ccTime) dt
{
    float32 timeStep;
    const int32 velocityIterations = 8;
    const int32 positionIterations = 3;

    // Average the previous TIME_STEPS time steps

    for (int i = 0; i < TIME_STEPS; i++)
    {
        timeStep += previous_time_steps[i];
    }

    timeStep = timeStep/TIME_STEPS;

    // step the world
    [GB2Engine sharedInstance].world->Step(timeStep, velocityIterations, positionIterations);

    for (int i = 0; i < TIME_STEPS - 1; i++)
    {
        previous_time_steps[i] = previous_time_steps[i+1];
    }

    previous_time_steps[TIME_STEPS - 1] = dt;
}

The previous_time_steps array is initially filled with whatever the animation interval is set too.

This doesn’t do what I would expect it too. On devices with a low frame rate it speeds up the simulation and on devices with a high frame rate it slows it down. I’m sure it’s something stupid I’m over looking.

I know box2D likes to work with fixed times steps but I really don’t have a choice. My game runs at a very variable frame rate on the various devices so a fixed time stop just won’t work. The game runs at an average of 40 fps, but on some of the crappier devices like the first gen iPad it runs at barely 30 frames per second. The third gen ipad runs it at 50/60 frames per second.

I’m open to suggestion on other ways of dealing with this problem too. Any advice would be appreciated.

Something else unusual I should note that somebody might have some insight into is the fact that running any debug optimisations on the build has a huge effect on the above. The frame rate isn’t changed much when debug optimisations are set to -Os vs -O0. But when the debut optimisations are set to -Os the physics simulation runs much faster than -O0 when the above code is active. If I just use dt as the interval instead of the above code then the debug optimisations make no difference.

I’m totally confused by that.

Answer 1

On devices with a low frame rate it speeds up the simulation and on
devices with a high frame rate it slows it down.

That’s what using a variable time step is all about. If you only get 10 fps the physics engine will iterate the world faster because the delta time is larger.

PS: If you do any kind of performance tests like these, run them with the release build. That also ensures that (most) logging is disabled and code optimizations are on. It’s possible that you simply experience much greater impact on performance from debugging code on older devices.

Also, what value is TIME_STEPS? It shouldn’t be more than 10, maybe 20 at most. The alternative to averaging is to use delta time directly, but if delta time is greater than a certain threshold (30 fps) switch to using a fixed delta time (cap it). Because variable time step below 30 fps can get really ugly, it’s probably better in such cases to allow the physics engine to slow down with the framerate or else the game will become harder if not unplayable at lower fps.