DeltaTime
The correct way of doing this is of course using deltatime.
I really need some cheating sheet what math (deltatime) I need to use and when.
Because it can be hard to implement that in some scenarios.
source:
https://medium.com/@tglaiel/how-to-make ... c61210fe75
Code: Select all
Vec3D p0 = position;
Vec3D v0 = velocity;
Vec3D a = acceleration*(1.0/60.0);
double f = friction;
double n = dt*60;
double fN = pow(friction, n);
position = p0 + ((f*(a*(f*fN-f*(n+1)+n)+(f-1)*v0*(fN-1)))/((f-1)*(f-1)))*(1.0/60.0);
velocity = v0*fN+a*(f*(fN-1)/(f-1));
Ok that last bit is literally cut and pasted from my engine utility code for “actual correct framerate independent move with speed-limiting friction” function and contains a little bit of extra cruft in there (those multiplies and divides by 60). But that is the “correct” variable timestep version of the previous snippit. I calculated it over the course of an hour or so with gratuitous help from wolfram alpha.
Now there’s going to be people saying why not just do:
speed += acceleration * deltaTime;
speed *= pow(friction, deltaTime);
position += speed * deltaTime;
And while something like that kinda works, it’s not actually correct. You can test it yourself. Do 2 updates of that with deltaTime set to 1, and do it once with deltaTime set to 2, and the results aren’t actually the same. Typically you want your game to run consistently, so having inconsistencies like this aren’t great. Its probably good enough if you know your deltaTimes are all around the same value, so then you need some code to make sure your updates are running at some kind of fixed rate and… oh. Right. We’re trying to do it the “CORRECT” way now.
If that tiny bit of code expands to that monstrous pile of math, imagine more complicated movement patterns involving multiple interacting objects and such. You can clearly see how doing it the “correct” way is infeasible. So the “rough approximation” is basically all you got. Lets ignore that for now and assume you actually do have the “actual correct” version of your movement functions. Good, right
I had the 'same' problem before as he describes below in a other 'game'.
You can jump about 1 tile high, and the game takes place on a grid of 1 tile blocks. Your feet need to clear the top of the block in order to land on it.
But since collision detection here is in discreet steps, if the game was running at a slower framerate your feet would sometimes not actually clear the top of the tile, even though the movement curve they followed was the same, and you would just slide down the wall instead.
This is obviously a solvable problem. But it illustrates the types of problems you encounter when trying to make your variable timestep game loop work correctly. You lose consistency and determinism, so you can just throw away the ability to do input replays or deterministic multiplayer and such.
Interpolation
The fun part is that you can skip the delta time, so no math problems
You need some extra variables, but the output is more 'correct', so a double win here.
but it's not particularly great because the former lags and the latter microstutters,
Ow
I din't see the microstutter in a other try-out (non love2d) but that was not tested 100%.
All the examples above say to use interpolation, but I don't know the correct way to implement that in love2d.
I will try to make a interpolation example, but I guess nobody is using it here
That makes me wonder if there is a full cheat sheet for the use of delta-time math for the most common things ?
So I will skip that interpolation thing and use delta-time without math mistakes, resulting in wrong vector movement.
