GMLDelta Time

Member
I'm trying to refine my delta time system. In side by side comparisons though I'm struggling to accomplish similarness. Maybe it is just what it is supposed to be but it seems a little strange. So all I have is two objects that do that fall to the bottom of the screen and bounce:

Code:
//normal version
vsp += grav;
y += vsp;

if (y >= room_height) {
y = room_height;
vsp *= -0.9;
}

//delta time version
vsp += grav * _dt;
y += vsp * _dt;

if (y >= room_height) {
y = room_height;
vsp *= -0.9;
}
The delta time calculation is close. I'm printing out the value of _dt each step and it is always either 1 or averages to one within a frame or two. Probably wouldn't be noticeable if they weren't side by side, but side by side the non-dt version definitely starts faster and they become offsync.

If I just set vsp to a number and do y += vsp and compare that to y += vsp * _dt the results are the same.

I'm familiar with this: Delta time calculations. But The version listed there is significantly worse.

This is half experiment and half a project that uses a variety of dts simultaneously (e.g. can change game, enemies, player, particle system, etc. together or independently). So it isn't for frame rate issues it is for speed control.

CloseRange

Member
Code:
vsp += grav * _dt;
y += vsp * _dt;
I havn't done delta time calculations in a while so forgive me if I'm wrong.
I belive you shouldn't be multiplying _dt on both, only vsp otherwise you are doubling the error correction meaning you have the same error you would without delta_time but in the other direction now.

Though I'm tired and could be wrong so instead use some good ol physics to see if it's wrong!
h is the starting height of the ball
g is gravity
the formula for finding how long a ball takes to fall is:
sqrt( (2*h) / g )
this assumes a mass of 1 but that's fine seeing as you don't care about mass.

Use this formula and compare it to how long it actually took for the balls to fall (using current_time)

IndianaBones

Member
• CloseRange

Yal

🐧 *penguin noises*
GMC Elder
Probably wouldn't be noticeable if they weren't side by side, but side by side the non-dt version definitely starts faster and they become offsync.
With rounding errors, you will get a steadily rising error if you keep adding floats to each other. (Unless they're expressible as a sum of powers of 2: 0.5, 0.25 etc... any other number cannot be losslessly expressed in a float, no matter precision)

And yes, gravity is inversely proportional to the square of the framerate, so if you double framerate you should use a quarter of your 1:1 gravity, and so on.

Member
I tried changing the dt calculation to this:

Code:
y += (vsp/2) * _dt;
vsp += grav * _dt;
y += (vsp/2) * _dt;
Which I believe is a correct interpretation of the version on this page taking into account that I am only changing the y variable:

Code:
pos = pos + (speed/2)*dt
speed = speed + acc*dt
pos = pos + (speed/2)*dt
And it is definitely less accurate than the prior version.

As is this:

Code:
y += _dt *vsp + 0.5 * _dt * _dt * grav;
vsp += _dt * grav;
Maybe the first version is as correct as it can be due to rounding errors. This is a single player only project where dt is being used for a high degree of control over movement, slow down, etc. not frame rate so close enough is probably fine, I was just curious as to why they don't match up more exactly. Maybe I'll upload a gif of the differences at some point.

But if anyone has ideas on greater how to achieve greater accuracy or where the problem is with my math or implementation of someone else's math let me know.