Legacy GM Delta Timing and Physics

O.Stogden

Member
Hey everyone,

I've been working on implementing Delta timing into my game, and everything is working fine, however I'm having a little trouble with the physics side of things.

I get that physics doesn't operate on the usual "step" system that the rest of the game runs on, so I've left the physics system entirely out of the delta time calculations, except the number I'm using to apply force to the car is being affected by delta time. (The car's acceleration stat is doubled at 30FPS for example)

Unfortunately when I ran tests, it doesn't quite add-up.

PC running at 60FPS:

Car reaches end of straight in approx 6.5 seconds.

Laptop running at 28-30FPS:

Car reaches end of straight in approx 8 seconds.

Also the car seems to drift a lot more at 30FPS, you have to steer much earlier for the corners as the car carries on in the forward motion for much longer.

I'm guessing this is because phy_speed is around 24 at 30FPS and around 12 at 60FPS, and this throws off the physics calculations for angular/linear damping and friction etc.

Does anyone have some tips on how to handle physics when adding delta timing?
 

matharoo

manualman
GameMaker Dev.

Nocturne

Friendly Tyrant
Forum Staff
Admin
Nope, that doesn't speed up the physics. I've actually tried everything I could and there is no way to delta-time physics... Just have to apply the delta factor to the forces manually.
Thanks for the feedback. It's not something I've ever tried, tbh, so it was a bit of a shot in the dark.... :)
 

O.Stogden

Member
Thanks for the input guys.

I have the car now accelerating at the right speed.

Unfortunately when the car goes into a drift, it becomes much harder to get out of the lower the FPS is.

Right now the variables that I'm affecting with delta time is the "gas" variable, which is a variable that goes from 0-1 depending on how hard you're accelerating, at 30FPS this gets doubled.

Code:
//gas_value gets set earlier on in the event, usually holds a value of 0 or 1.
gas_value=gas_value*global.dt_steady
forward_x = (lengthdir_x(accel, -phy_rotation - 90) * gas_value)
forward_y = (lengthdir_y(accel, -phy_rotation - 90) * gas_value)
physics_apply_force(x, y, forward_x, forward_y)
And then I have turning variables, which affect how the car rotates:

Code:
if global.class='Hyper'
{
turning=(3*clamp(phy_speed,0,1))-(0.25*clamp(phy_speed/5,0,5))*global.dt_steady
}

if leftarrowheld=true
{
phy_rotation-=turning
}
if rightarrowheld=true
{
phy_rotation+=turning
}
Visually this looks great, and it all appears to work fine, the car accelerates at the same speed and it rotates/turns at the same speed, regardless of FPS.

Unfortunately if I'm at 60FPS and go round a corner at a phy_speed of 10, I can get around the corner fine.

If I'm at 30FPS and go round a corner at a phy_speed of 20 (the equivalent of 10 at 60FPS), then the cars inertia drags it off the track, because it can't seem to push it in the right direction fast enough, even though it accelerates on a straight identically to the 60FPS game.

I'm thinking I'm missing something obvious here, but lower FPS = higher phy_speed which causes unpredictable results. And I haven't figured out a way around that.
 

GMWolf

aka fel666
Here is the thing about physics: you don't want to run it a variable speeds. Because some things are very hard to integrate correctly.

Really what we should be doing is keeping the physics frame rate entirely separate from the graphics frame rate.
And doing all our logic calculations (applying forces and so on) at the same rate we do physics.
Unfortunately with GM, we can't control when we call the physics update function.
Until we get that there is basically no way to correctly do our physics simulations in a stable way.
 
Top