# Box2D simulation running slower on lower FPS(even when the desired FPS is lower than the actual)

I´m playing around and trying to make myself an easy platformer using the Box2D physics, before that I was not using it and was using my own physics implementation(just simple movements with timestep). My gameloop architecture now works like this:

while (_isRunning) {

//Processing input events
processInput();

update();

//Rendering stuff
startFPSCap();

render();

delayFPS();
}


The update function is consisting of updating a game world (normal update function without deltatime) - inside this I´m calling a Box2D step function, with desired timestep at 1/60(wanted to have simulation at 60 fps) and then I call my own timestep function to update entity components(so they can be updated also with timestep not just the physics).

void update()
{
_physics->Step(1.0f / 60.0f, 6, 2);

updateEntitiesWithOwnTimestep();
}


However when I tried to run it on slower FPS, the simulation slow downs (even when I capped the FPS to like 200 at the start, so running it at 100 fps is like a slowmotion). I thought that when I set the desired physics simulation for 60 fps it will be no problem when reducing the FPS, but it seems like I´m missing something. Or is there something wrong? I mean, maybe the fact I´m running also my own timestep function.. Thanks for help.

Edit1 - according to Timos answer

Do you mean I should put the delta value I pass to my update function during each step in my own timestep? Like this:

void TimestepManager::update() {

int i = 0;

while ((_totalDeltaTime>0.0f) && (i<MAX_PHYSICS_STEPS)) {

_deltaTime = std::min(_totalDeltaTime, MAX_DELTA_TIME);

//This is std::function - i can define my own behavior via this
_f.exec(_deltaTime);

_physics.Step(_deltaTime, 6, 2);

_totalDeltaTime -= _deltaTime;

i++;
}


}

Or should I pass the total deltaTime? Because I thought that I should keep this unchanged because I don´t want to tie the simulation with the FPS.

You should calculate it and supply that to the step method instead of the hardcoded 1.0f / 60.0f value.
• @Pins, your edit is close to a different solution: implementing a fixed timestep for physics, packing more or fewer steps at this fixed rate into each frame to keep pace with real-time. To make this exactly a fixed timestep solution, you'll want to: 1) Remove the min, keeping _deltaTime constant 2) Carry the "loose change" time / time debt remaining in _totalDeltaTime into the next frame (whether you want to run up to one step ahead or one step behind is up to you) 3) (optional) interpolate between the last two physics steps to ensure smoothness when frames land between physics steps. – DMGregory Feb 11 '18 at 18:05