Page 1 of 1
I need help on FPS management
Posted: Sat Feb 22, 2025 1:32 pm
by 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
Re: I need help on FPS management
Posted: Sat Feb 22, 2025 3:10 pm
by 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.)
Re: I need help on FPS management
Posted: Sat Feb 22, 2025 5:24 pm
by 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.
Re: I need help on FPS management
Posted: Sat Feb 22, 2025 5:46 pm
by ivan
Your physics joints are going to be unstable/unpredictable if you don't use a fixed time-step.
Re: I need help on FPS management
Posted: Sat Feb 22, 2025 6:46 pm
by 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.
Re: I need help on FPS management
Posted: Sun Feb 23, 2025 7:18 am
by 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.
Re: I need help on FPS management
Posted: Mon Feb 24, 2025 11:09 am
by 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.