1
\$\begingroup\$

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.

\$\endgroup\$
0
\$\begingroup\$

The first argument of the step method is the frame delta, the time between the last and the current frame. In your example it it the time between the last and the current iteration of the update method.

You should calculate it and supply that to the step method instead of the hardcoded 1.0f / 60.0f value.

\$\endgroup\$
  • \$\begingroup\$ I´ve edited the question, so you can see what I tried to edit. Is it the first or the second solution? \$\endgroup\$ – Pins Feb 11 '18 at 17:17
  • \$\begingroup\$ @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. \$\endgroup\$ – DMGregory Feb 11 '18 at 18:05
  • \$\begingroup\$ @DMGregory is it needed? I mean, is my timestep implementation causing the problem? Because before that, the Box2D´s step function was outside the loop in a normal update function, so it had its own timestep calculation(i guess). Or do I need to put it in my timestep? I dont want it to be tied with FPS \$\endgroup\$ – Pins Feb 12 '18 at 10:19
  • 1
    \$\begingroup\$ @Pins No, you don't have to do anything at all. You can make your game in any way that makes sense to you. Fixed timesteps are generally regarded as a good practice that makes it easier to get consistent behavior from our game sims, but not every game needs that level of consistency to play well. \$\endgroup\$ – DMGregory Feb 12 '18 at 12:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.