I need help on FPS management

[Briella]

I have a physics simulation that basically explodes if deltaTime is too big

I tried to implement a system that doesn't allow the simulation fps to get lower than minFps
basically it will appear slowed down but will keep simulating at whatever framerate I put there

https://pastebin.com/gCFD8Ypi
I wanted to ask if this is the correct way of doing this, or if there is a better way

[ivan]

This is a better way to update your physics simulation and is called using a fixed time-step.

Code: Select all

local accum = 0
local step = 1/60
function love.update(dt)
  accum = accum + dt
  local skipped = 0
  while accum > step do
    accum = accum - step
    world:update(step)
    skipped = skipped + 1
    if skipped > 10 then
      break
    end
  end
end

This technique may result in skipped frames once in a while, but it will ensure that your physics system is deterministic.
You will be able to replay the simulation and it will produce the exactly same output each time (as long as the "step" variable remains the same.)

[RNavega]

Nice. Can a similar result be achieved by putting a top cap on the 'dt' variable?

Code: Select all

function love.update(dt)
    local capped_dt = dt >= 1.0/60.0 and 1.0/60.0 or dt
    -- Use the capped dt for both the game engine and the physics sim.
    my_game_engine:update(capped_dt)
    world:update(capped_dt)
end

Edit: whoops, I just read OP's pastebin, that's the change that they're asking about.

[ivan]

Your physics joints are going to be unstable/unpredictable if you don't use a fixed time-step.

[RNavega]

In practice, I think both the frame-skipping mechanism (from your example) and the framerate-capping mechanism (from OP's pastebin) will keep the game engine and the physics stable, but will have different priorities when it comes to presenting the game.

So, imagine there's too much stuff happening in the game and the framerate decreases below the display refresh rate, making the game slow down. In this situation:
- The frame-skipping will try to keep game closer to what it should be if it was ideally running. The game might do some skips to some future state. I think this is necessary when it's a multiplayer game, though for network games it's probably more complicated to keep things in sync.
- the framerate-capping will try to simulate every game frame so the user doesn't miss anything. This should be better for like bullet-hell shoot'em ups where you don't want the player to bump into an enemy shot because of frames being skipped.

The reason I don't like the fixed-framestep mechanism is that, if the device isn't capable of running the game updates with the desired rate already, then running multiple updates on the next update cycle (that WHILE loop) will probably miss as well.

[ivan]

If you have complex contraptions using different types of joints, it becomes quite difficult to keep the simulation stable. According to the Box2D documentation, physics joints may become unstable when the delta value varies too much. I can confirm that joints can become springy and unpredictable when using a variable time-step. Using a fixed time step is a simple method to keep the simulation deterministic.
Variable time steps are good for animations, but for physics there are many advantages to using a fixed time-step.

[pgimeno]

Deterministic physics is a desirable property - I can't help remembering the test that grump proposed: viewtopic.php?p=245468#p245468

But it's not always necessary, and all the OP was asking is how to deal with high dt values (aka lag spikes). For that simpler goal, capping dt is more than enough.