Clarifying dt (delta-time) characteristics

These questions stem from the scirra.com/tutorials/67/delta-time-and-framerate-independence/page-1 that I read. I understood the information in general, but I had a few questions regarding the nature of dt that didn't quite seem to be answered.

1) A tick is what, exactly, compared to FPS? I get the impression they're the same thing, but I wasn't sure...

2) Why the "60*dt"? I'm assuming that's to accommodate for 60 FPS even if it's closer to 30 ticks on slower computers? How would you translate "60*dt" in layman terms?

3) With timescaling, you're basically manipulating the realtime value of dt, correct? So a slow-mo would be telling C2 that the dt is 1 when the real value is 2...something like that.

I do understand that dt is the amount of time in seconds passed since the last tick (usually, if not ALWAYS, a fraction of a second).

I also understand that dt is better than counting ticks as ticks can greatly fluctuate on slower computers, whereas dt can still keep track of the amount of time passed without hardly any interruption.

1/ A tick is a frame. When you're game is executing at 60 FPS, it's producing 60 ticks in a second.

2/ If you have an action executed every ticks (frames) that moves a sprite by "60*dt" pixels to the right, the sprite will have moved "precisely" by 60 pixels in a second. In that case, it's more the amount of pixels/seconds you're shooting for, not the FPS.

If you only have 30 FPS, the sprite will STILL have moved by 60 pixels in a second.

3/ Pretty much correct.

Kyatric - I think I'm clear on #1 and #3. Back to #2...

Maybe my confusion on the "60*dt" is that I'm thinking this is a GENERAL thing when it's really just a reference to an element for movement in pixels (well, per the example) regardless of FPS. (This is an example of me having trouble even clarifying what exactly my confusion IS.)

So I'm thinking... If "60*dt" moves a sprite 60 pixels per second, if we changed it to "30*dt", then...30 pixels?

Okay...let's see if I can't work this out and answer my own question.

Just to make things simple ("simple"...coming from me? Yeah right)...let's say we've got an absurdly slow computer running at 5 ticks/FPS. (Can you say "GIANT paperweight"?)

C2 runs through all the Events...we have one tick...and so on...

RUN TIME: dt 0

Tick 1: dt .21 (Total dt .21)

Tick 2: dt .19 (Total dt .40)

Tick 3: dt .20 (Total dt .60)

Tick 4: dt .22 (Total dt .82)

Tick 5: dt .18 (Total dt 1)

------------------------------

TOTAL dt: 1 second

Now, every tick, we multiply that by 60.

Tick 1: 60 * .21 = 12.6

Tick 2: 60 * .19 = 11.4

Tick 3: 60 * .20 = 12.0

Tick 4: 60 * .22 = 13.2

Tick 5: 60 * .18 = 10.8

------------------------------

TOTAL: 60 (kind of a "duh")

So! *a light suddenly starts to grow brighter this very moment* Every TICK - whenever C2 makes it's pass over the Events...THEN!...it checks to see how much time in a SINGLE SECOND has passed, and passes THAT VALUE to the action to tell it to move the sprite that many pixels. Soooo, basically, we're passing a value that is a FRACTION of the total of 60 pixels we want it to MOVE after one second. So even if the FPS were slower (say, the near-frozen 2 FPS), while the individual dt would be a larger amount, in of itself, after ONE SECOND, the SAME number of pixels total would still be passed - that is, 60. For at 2 FPS, each individual dt would be roughly .50, HOWEVER, 60 * .50 dt * 2 FPS STILL adds up to 60 (yay for math!).

I think the #1 point I need to REMEMBER is that dt is "the amount of time passed BETWEEN ticks/FPS DURING a SINGLE SECOND".

Thank you for bearing with me here. Initially, I just didn't get why the whole "60*dt" was so important. It was JUST a way around slower framerates to still present a 60 FPS flow...

That's pretty much it, yeah? LOL

Yeah, it sounds like you've pretty much got it now. Dt is enormously helpful, and not just for running games on slower computers. My last project had a lot of timing-sensitive sections, where a safe path to the player only opened up when certain elements were aligned. Without dt, there'd be no way for me to ensure that all my objects/enemies/whatever were moving/operating at the exact same rate, so there'd be no way to guarantee that they'd all line up they way they needed to so the player could make their way through.

Rhindon - your definition of dt as "the amount of time passed BETWEEN ticks/FPS DURING a SINGLE SECOND" is not exactly right. It's not averaged over a second or anything like that. dt is literally only the time in seconds since the last tick - that is the full definition. It normally is about 16ms or 0.016, corresponding to a screen refresh rate of 60 Hz (since 1 / 60 = 0.016), but can change depending on the framerate.

However dt has the property that over one second, the sum of every frame's dt also adds up to a second. (Hopefully that's faily obvious!) In fact over any period of time T, dt will sum to equal T.

That means that if every tick you add dt to a number, it increases by 1 a second. Therefore, if you add n * dt to a number, it increases by n every second. This isn't to do with the actual definition of what dt is, it's just what mathematically follows from how dt works.

The reason I chose 60 * dt in the example and not a different number is if you have done the following event -

Every tick: set sprite X to Self.X + 1

then this is framerate dependent, and moves at different speeds depending on the framerate. However, most computers are fast enough to render at the screen refresh rate, which is usually 60 Hz. So most of the time it will move at 60 pixels per second. If you want an object to move at 60 pixels per second in a framerate independent way, you would use Self.X + 60 * dt. As we showed before this will move the object 60 pixels a second, regardless of the framerate. So you can make changes like this and the object will probably appear to move at the same speed, but now it's framerate independent.

Hopefully that helps clear it up!

*CHUCKLES* This is one topic that I wish there was a comparison/side-by-side chart showing how ticks/FPS and dt and screen refresh works and differ.

whiteheat - In theory, I definitely understand now, especially when it comes to making sure objects do what they ought to WHEN they should. In practice, I'm not there yet. Just the other night I got my test/learning program (not an actual game I'm building) implemented with dt so that it runs as before, but without tick dependency. I think the the obvious next step is learning to THINK in dt and not confuse it with ticks/FPS.

Ashley - "dt is literally only the time in seconds since the last tick"...THAT clears that bit up nicely. Thank you.

Whenever the "n*dt" gets brought up, one thing I keep forgetting is that dt is typically (always? ...I believe always) a fraction, which is why it usually adds up to 1 every second. (My apologies, it just helps if I can try to explain the same thing told to me in my own words to check that I understood accurately.)

So, with the Every Tick --> Set sprite X to Self.X+1, if the tick/FPS is 30, the sprite will only move 30 pixels. Or 60 if the tick/FPS is 60. Thus the dependency. But, as I believe you just stated, dt correlates with the screen refresh - that is, an update to the present images on the screen as they should be at any given time.

Heh, I know I may be complicating this more than need be, but this is the odd way my brain filters information. Thank you, as well, for bearing with me.

How'd I do...again? LOL