Delta time - what's the best way?

OK, it's going to be time soon for me to do something I've been putting off for years: implementing Delta Time in my game. Up until now I've just been using "machine independent speed", which I believe isn't the optimal method. I've seen Delta Time mentioned many times here and there, and found a couple of short examples, but I haven't yet found a really definitive tutorial for it. So, I was hoping some people could help steer me in the right direction. I guess I have a few questions:

1. first off: how do you do Delta Time? X)
2. Are there multiple methods? Is one superior to the other? Would one or another be better an already-built engine that uses fastloop- and float-point-based custom movements, and is for Windows?
3. Are there any best practices to be aware of?
4. Are there any nasty surprises or pitfalls I should be aware of?

Thanks!

I have no real experience with it but a time ago i read this article its very good and maybe helps you :) https://www.scirra.com/tutorials/67/...e-independence

I don't have a lot of experience with Delta Time, but these old threads come to mind:

https://community.clickteam.com/threads/51408-Advanced-techniques-in-MMF2
https://community.clickteam.com/threads/70671-MushMush-Frame-Independent-Multiplatform-Engine?p=522740&highlight=#post522740

I would personally much prefer using a "delta time" loop as opposed to multiplying any expression by the delta time (as the Scirra article suggests). I'm not sure, but I can see far too many potential collision errors happening from that.

I made at least one game frame rate independent, basically you'll use the timer value to calculate all changes/movements between frames.
timecalc = timer this frame - timer last frame. Recommend limiting with a minimum and max value, and can be multiplied to adjust gamespeed.
timecalc must then be used accurately with all movements in the game, this is tricky but possible.
Using loops can help to replace previous "always" events, make a loop called "ticker" which triggers 30(previous framerate) times per second f.ex, add timecalc to a value 'trigger'
then:
if trigger > 89, do loop "ticker" 3 times, subtract 90 from trigger.
if trigger > 59, do loop "ticker" 2 times, subtract 60 from trigger.
if trigger > 29, do loop "ticker" 1 time, subtract 30 from trigger.

the above would support a framerate as low as 5fps and still have all your always events accurate. (on loop "ticker")

this doesn't help to smooth things out with high framerate tho, which is what you mainly want, use the actual timecalc value for that.

Quote:

---

Originally Posted by SoftWarewolf

I made at least one game frame rate independent, basically you'll use the timer value to calculate all changes/movements between frames.
timecalc = timer this frame - timer last frame. Recommend limiting with a minimum and max value, and can be multiplied to adjust gamespeed.
timecalc must then be used accurately with all movements in the game, this is tricky but possible.
Using loops can help to replace previous "always" events, make a loop called "ticker" which triggers 30(previous framerate) times per second f.ex, add timecalc to a value 'trigger'
then:
if trigger > 89, do loop "ticker" 3 times, subtract 90 from trigger.
if trigger > 59, do loop "ticker" 2 times, subtract 60 from trigger.
if trigger > 29, do loop "ticker" 1 time, subtract 30 from trigger.

the above would support a framerate as low as 5fps and still have all your always events accurate. (on loop "ticker")

this doesn't help to smooth things out with high framerate tho, which is what you mainly want, use the actual timecalc value for that.

---

Sorry, I'm not understanding the "trigger" part very well/ Do you mean that I'd need to use a fastloop for every "always" event (and presumably other types of events to, in many cases)? I hope not, because that sounds like a nightmare to implement, and would surely cause lots of slowdown.

Or do you mean that you would do the fastloop once, and then replace all always events with if trigger>1?

All movements must use timecalc (milliseconds since last frame) or loops.
f.ex if you are doing something that has to do with time or movements and your standard framerate is 50, then when the framerate drops to 25 it must be done two times on the same frame.

I got the above answer wrong, (but not by much) for 50fps the timecalc would be 1000 / 50 = 20. replace 50 with the original framerate and do the math again.
So you want to run a loop ever 20 milliseconds, to do so add the amount of milliseconds since last frame to a value,
then if the value is:
>59 - do the loop 3 times and subtract 60.
>39 - do the loop 2 times and subtract 40.
>19 - do the loop once and subtract 20.

^ supports up to 6 loops, or a framerate as low as 50/6 = 8.33fps

If the framerate is higher f.ex 100 fps, then the loop only triggers every 2 frames, so to get more smoothness with higher framerate you have to calculate with the [milliseconds since last frame] directly.
Movements should be based on float variables (alterable values) so you can get sub-pixel precision. f.ex move from 100.2 to 100.4, set the actual position with round(value)

I used delta/framerate independence on this game: https://community.clickteam.com/threads/99218-Alien-Run-Free-Bitcoin-(iOS-Android)

Yeah with delta time loop method you would have to replace every "always" event with the delta loop, as well as any "key down" events, etc.

It will be a nightmare to modify an already existing project with many time sensitive events, but it isn't too bad if you design your game around it. The loop method is the simpler of the two (loops vs designing expressions around delta time) but more expensive technically. I doubt you would need to worry about performance with the loops unless you forsee the game dropping low enough to fire the delta loop tons.


Using SEELE's (loop) method, here's an example of floating point movement and delta time: Attachment 22829

The frame rate is 10 but the target is 60.


The other way would be to multiply every velocity in your game by a calculation that uses delta time instead of using a fastloop. With both methods you would probably need to make a custom animation system so you can control frame advancing and include delta. I imagine animations would look wonky if just left alone.


EDIT: As a neat addition, you can lower the "target framerate" value to simulate slow motion, too X)

Hmm, one of the reasons I wanted to do Delta Time was because I was under the impression that it would be faster than Machine Independent Speed (which I'm using currently). Though with all those fastloops, I'm wondering whether it would be faster at all. Adding an "on loop" condition to hundreds of events won't be without a cost.

I guess maybe I should first ask another question: what are the pros/cons of Machine Independent Speed VS Delta Time? Like I said, I'm using that now, and it works fine. I'd heard rumours that it has performance issues, but I've never seen hard evidence of this.

I wouldn't know the intricacies myself, but I think SEELE did a number of tests and addressed this in that thread I linked: https://community.clickteam.com/threads/51408-Advanced-techniques-in-MMF2

Also remember that you can do delta time another way (with a calculation in your expressions, like the Scirra article uses) if you absolutely can't use the loop method. Just keep in mind the inaccuracies the article mentions.

From what I can gather, you'd really need to do it both ways, right? The multiplier method of the Scirra article would be fine for movements, but I couldn't use a multiplier for things like:

Always
-add 1 to gunTimer

gunTimer=100
-launch bullet

EDIT....or - wait - I guess I could?
-add 1 * deltaTime to gunTimer?

Quote:

---

Originally Posted by casleziro

I wouldn't know the intricacies myself, but I think SEELE did a number of tests and addressed this in that thread I linked: https://community.clickteam.com/threads/51408-Advanced-techniques-in-MMF2

---

oh, ok. Forgive me - I haven't read those threads yet

Yeah the idea would be to add 1 * deltaTime to the timer.

I'm not sure if I got it right, but here is an attempt at the multiplication method: Attachment 22830