LÖVE

Posted: **Thu May 31, 2012 3:36 am**

Hi!
I'm having some trouble wrapping my brain around framerate independent programming. It seems to be worse than using a fixed timestep, iterating multiple times when catching up is needed. My biggest concern is game logic changes based on fps. Example: Pixel A is traveling 1 pixel per second towards pixel B. Both are 1 pixel in size. If the game lags to over a second, pixel A could move faster than 1 pixel per second and jump over pixel B, not colliding. This of course can be avoided by more clever code, but wouldn't it be easier to assume a certain speed in your update loop to avoid programming around these issues? I also feel the need to account for dt being as small as 0.01 or as large as a whole number(worst case) opens up more possibilities for bugs.

What are some of the advantages of using the dt for calculations vs a fixed timesteps? Are there any articles that talk about this kind of stuff?

Posted: **Thu May 31, 2012 6:02 am**

DeltaTime isn't that hard to figure out. And you CAN use framerate independence if you turn on VSync. Independence is the same as using dt except that dt is always 1/60. (0.016666666666666667)

You're moving something at a rate of 100 pixels per frame, you move it by 100 * dt. Simple as that. You'll need to use dt no matter what. Just get used to it. It is amazing. Embrace the Delta. Join us. Join us. And so on. Maybe someone else can explain better.

Just think about it as "This needs to happen at this speed per second" or "This needs to take this many seconds to finish" and just multiply it by dt.

Posted: **Thu May 31, 2012 7:32 am**

Orange wrote:Pixel A is traveling 1 pixel per second towards pixel B. Both are 1 pixel in size. If the game lags to over a second, pixel A could move faster than 1 pixel per second and jump over pixel B, not colliding.

Not so. If Pixel A moves mores less because dt is smaller, B will also move less because dt is smaller. They will end up colliding, when the same time has passed. But you will have had more frames showing it.

Orange wrote: What are some of the advantages of using the dt for calculations vs a fixed timesteps?

The main advantage that I see is that it makes games more capable of running in

Say that you are programming a game with some intense logic. In a powerful computer it will run at 60 fps with no issues. It can calculate everything in 1/60 of a seconds, and has processing power to spare.

With a fixed frame, you could do things like "move the player 2 pixels to the left on each frame". In one second it would move 60x2 = 120pixels.

Now imagine that you try to execute the game in a smaller machine, much slower than the big PC (maybe an android phone). On that machine, all your logic, takes so much time that it finishes once every 1/40th of a second - so you get only 40 fps (which is still good for a game to be playable).

But now, since your code said "move the player 2 pixels to the left", you would get 40x2 = 80 pixels, instead of the "standard" 120.

In other words - on the smaller machine, the game would appear to "go slower".

If you had used variable framerate, on the first machine the player would move 2 pixels each frame, but on the smaller one it would move 3 pixels each frame. The game would play the same on each machine.

Another interesting case is when you have a game that normally runs ok at 60fps, but some game parts are so logically intensive that the fps goes down. With variable framerate, you can "compensate". With a fixed framerate, the game just "slows down".

Suming up -

In the smaller computer, the game would move more slowly.

Posted: **Thu May 31, 2012 7:33 am**

Jasoco wrote:And you CAN use framerate independence if you turn on VSync. Independence is the same as using dt except that dt is always 1/60. (0.016666666666666667)

I beg to differ, first of all vsync is a request at most, nothing guarantees it will be on if you ask for it, then vsync typically limits your game to 60 fps, but is really just common, not a rule. Let's not forget you can go slower, and that won't be in your calculations, nor corrected for with vsync, and then there's vsync implementations that keep halving your cap if you don't reach the target framerate, so 30 fps, if you don't get up to 60 (but you would have 58).

Posted: **Thu May 31, 2012 7:39 am**

kikito wrote:
Orange wrote:Pixel A is traveling 1 pixel per second towards pixel B. Both are 1 pixel in size. If the game lags to over a second, pixel A could move faster than 1 pixel per second and jump over pixel B, not colliding.
Not so. If Pixel A moves mores less because dt is smaller, B will also move less because dt is smaller. They will end up colliding, when the same time has passed. But you will have had more frames showing it.

Yes, but he's talking of a bigger dt, not smaller. If we had A and B adjacent, each one moving towards the other, and the game lagged for more than 0.5 seconds, we'd have dt > 0.5, so both A and B would move more than 0.5 pixels towards the other and they would 'jump' over the other, if I recall well I could simply have said "tunneling" instead of this example

Posted: **Thu May 31, 2012 7:51 am**

Nixola wrote:Yes, but he's talking of a bigger dt, not smaller. If we had A and B adjacent, each one moving towards the other, and the game lagged for more than 0.5 seconds, we'd have dt > 0.5, so both A and B would move more than 0.5 pixels towards the other and they would 'jump' over the other, if I recall well I could simply have said "tunneling" instead of this example

Sorry, you were right.

The solution in that case comes in two parts:

Have a "maxdt" cap in your love.update, so that if the screen lags too much, or the user moves the window around with the mouse, your logic isn't screwed
Don't use pixels for colliding. Use a bigger thing - one whose minimum size is maxdt*maxspeed. With a maxdt of 0.05 seconds and a maxspeed of 500 pixels/s, you should be using 25x25 boxes instead of pixels if you want to avoid tunnelling.

Posted: **Thu May 31, 2012 12:42 pm**

kikito wrote:
Have a "maxdt" cap in your love.update, so that if the screen lags too much, or the user moves the window around with the mouse, your logic isn't screwed

Right, but doesn't that take the point out of framerate independent programming?

Also, I've been searching through the source of Mari0 and found this snippit at the very top of the main update loop

Code: Select all

dt = math.min(0.01666667, dt)

This limits dt to never go over 0.01666667. What effects happen when the framerate drops to go over that? Obviously dt is limited, but what would the user see?

Posted: **Thu May 31, 2012 1:35 pm**

With variable framerate you get an interval in which the app works ok, "skipping" frames if needed. And then a slowdown below certain threshold.

With fixed framerate you get a slowdown the moment you are not "on max" .

Posted: **Fri Jun 01, 2012 1:22 pm**

Two great articles on the subject:

http://gafferongames.com/game-physics/f ... -timestep/
http://www.koonsolo.com/news/dewitters-gameloop/

LÖVE

Understanding framerate independent programming

Understanding framerate independent programming

Re: Understanding framerate independent programming

Re: Understanding framerate independent programming

Re: Understanding framerate independent programming

Re: Understanding framerate independent programming

Re: Understanding framerate independent programming

Re: Understanding framerate independent programming

Re: Understanding framerate independent programming

Re: Understanding framerate independent programming