Fix For Laggy Delta Time

[squidborne_destiny]

Hey guys, so I was having some trouble with Delta Time being laggy, even with my lightning fast computer. This resulted in my jumpy motion and unstable velocities, as well as crappy graphics. It was especially annoying because there was no easy fix, but after reading around and doing a little research I came up with a function that should help fix the problem. So if you've been struggling with this problem, struggle no more.

Code: Select all

frame = 1
dt1 = 0
dt2 = 0
dt3 = 0
function love.update(dt)
if frame == 1 then
dt1 = dt
frame = 2
elseif frame == 2 then
dt2 = dt
frame = 3
elseif frame == 3 then
dt3 = dt
frame = 1
end
DT = ((dt1+dt2+dt3)/3)
	
end

Also, adding more dt's to the equation will allow for smoother performance. Let me know if you have anything for me to add to this function.

[micha]

Could you please upload a .love file of you code, so that we can try to reproduce the laggy behavior?

[Evine]

If vsync is enabled and the game isn't very demanding. Then just getting the dt from the monitor refresh rate is probably the best solution. Of course you'd need to write some logic to handle computers without vsync and possible love.window.getMode() refreshrate errors.

Code: Select all

refreshrate = select(3,love.window.getMode()).refreshrate
function love.update(dt)
    DT = 1 / refreshrate
end

Could you please upload a .love file of you code, so that we can try to reproduce the laggy behavior?

dt isn't consistent. So relying on the previous frame dt isn't a good way to calculate the next frame.

[s-ol]

Hey guys, so I was having some trouble with Delta Time being laggy, even with my lightning fast computer. This resulted in my jumpy motion and unstable velocities, as well as crappy graphics. It was especially annoying because there was no easy fix, but after reading around and doing a little research I came up with a function that should help fix the problem. So if you've been struggling with this problem, struggle no more.

Code: Select all

frame = 1
dt1 = 0
dt2 = 0
dt3 = 0
function love.update(dt)
if frame == 1 then
dt1 = dt
frame = 2
elseif frame == 2 then
dt2 = dt
frame = 3
elseif frame == 3 then
dt3 = dt
frame = 1
end
DT = ((dt1+dt2+dt3)/3)
	
end

Also, adding more dt's to the equation will allow for smoother performance. Let me know if you have anything for me to add to this function.

why in the world would you try to middle dt? You are supposed to use dt as a coefficient for "things-over-time" so that the lag goes away. dt is designed to be unstable, if it were stable it would not be a parameter. LÖVE is using a variable timestep game loop. You might find this article useful: http://gameprogrammingpatterns.com/game ... giant-step

[Evine]

dt output. vsync enabled.

Code: Select all

0.016141746193171
0.016393890138716
0.01650405395776
0.016975623555481
0.016420305240899
0.016438916325569
0.015358597505838  -- Imagine what will happen here.
0.017257184721529  -- You compute this frame with the dt above. 
0.016084713395685
0.015919318888336
0.01655058003962
0.016801223624498
0.016664645634592
0.016729782801121
0.017565761692822
0.016807226929814
0.016755898017436
0.016335656866431
0.017065975349396
0.015405124053359
0.016760100144893
0.016644534189254
0.016797921620309
0.016546978149563
0.016800923738629
0.016598907765001
0.017149122897536
0.016222792677581
0.017101395875216

As you can see from my dt output isn't stable at all. But the screen I'm using will display each of these frames closer to "0.016666666666667"ms. Thus using dt directly will cause some unwanted stutter.

[s-ol]

dt output. vsync enabled.

Code: Select all

0.016141746193171
-snip-

As you can see from my dt output isn't stable at all. But the screen I'm using will display each of these frames closer to "0.016666666666667"ms. Thus using dt directly will cause some unwanted stutter.

Do you have a demo where this is a noticeable effect? Not computing a "fake" dt is important when doing time-critical work, for example to keep difficulty constant or in multiplayer applications.

[Evine]

The effect isn't very noticeable most of the time. But due to my computer having a broken "love.timer.sleep()" function, it became very apparent as the dt jumped between 0.0333 and 0.0167 (Due to vsync either doing every frame or every half frame)

Here's also an great explanation on why using the previous frame dt might be a problem.
https://forums.handmadehero.org/jace/vi ... ay018.html

[s-ol]

But due to my computer having a broken "love.timer.sleep()" function

What do you mean "broken"? timer.sleep() is barely ever appropriate (except maybe in love.run) and it's supposed to block execution and break your deltatime.

About the video: Yes, there are disadvantages in using a variable timestep, and that's fine. If you want a fixed timestep, then modify your love.run, that way you don't have to mess around with "incorrect" dt and do weird hacks like that code above.

[Evine]

This is my lovely dt with "love.timer.sleep" enabled. The problem is "love.timer.sleep" is way to sleepy and sleeps for 0.015-0.017ms no matter what. Thus interfering with my framerate.

Code: Select all

0.020445311442018
0.015627551358193
0.017244277521968
0.015619446989149
0.021231761202216
0.015639258082956
0.021267482079566
0.015521290712059
0.0051464480347931
0.031460720580071
0.021230861078948
0.014650191646069
0.016986429691315
0.018868507817388
0.017200152389705
0.015620647463948
0.020693253260106
0.020466323010623
0.015626951120794
0.017073479481041
0.01701224502176
0.015628151595592
0.020724170841277
0.015626350883394
0.015613743569702
0.00498525518924
0.020089006982744
0.015723606571555
0.018151397351176

About the video: Yes, there are disadvantages in using a variable timestep, and that's fine. If you want a fixed timestep, then modify your love.run, that way you don't have to mess around with "incorrect" dt and do weird hacks like that code above.

He does have a variable timestep. But dt is fixed to the monitor refreshrate at the start. And he explains very well why that is the better choice.

[T-Bone]

I really don't see why variance in dt is a problem. It feels like the only issue here is that you assumed your dt would be constant with vsync (which it often is, but it can never be guaranteed). Let dt vary as much as you want, and write code that works regardless of framrate, that's the easiest way to make games that run on more or less any computer.