Why dt? [QUESTIONS ANSWERED, RESUME YOUR DAILY LIVES]

[Puzzlem00n]

So, we all know what dt is, right? We'd have to to make anything move or tween in this engine. It's an integral part of our framework.

When you see a newbie post come along about what dt is, the answer is generally the following. Love.update is called every frame. Frames, though, are not always the same length. So, if you were to try and tell something to move 3 pixels left every frame, it would move erratically at a strange and almost unpredictable pace. So, the brave and noble developers of LÖVE (I wish I could hack my keyboard and give it that Ö...) added the delta time feature, an internal counter that tells you how much time, in seconds, has passed in the last frame. This way, you could take this so called "dt" and use it as a transformer of the amount you want to move every second. This creates the illusion of smooth movement.

Of course, you have to be careful, as too high a dt from a slow framerate can mess up collisions. It's useful to limit dt through math.min, then, or use timestepping...



Hold up. Why on earth are we doing this?

It's recently occurred to me, and I'm sure to many others at some point, that there is an obvious solution to this problem that would fix everything with no dt involved: a timer with guaranteed equal increments.

You could somehow set it up in conf.lua somehow like this:

Code: Select all

function love.conf(t)
   t.updateTime = 0.07
end

And then every time that amount of time (in seconds) passed, love.update would be called.

Now, someone who has read through all this writing is probably thinking I'm suggesting we scrap dt and do this instead. Well, I'm not. I know there has to be a reason this wasn't done, otherwise it would be suggested all the time. (Perhaps it has. I don't know, searching the forums isn't turning up anything. Did you it doesn't even accept "dt" as a valid search term? Anyway, back on topic.)

Basically, I want to know why this wasn't done. Timers seem like such an obvious solution. Is there something I don't understand about the workings of C++? If anyone could shed any light on this, I would greatly appreciate it. Dt, from my perspective, seems very unnecessary.

[Tesselode]

If you used an update time like you are suggesting, that timer would still be using dt, and would still have all of the same problems as dt. The only difference is that you wouldn't have to include dt in your code.

Game Maker uses frames instead of seconds, which is OK, but it means that if the framerate ever drops below the intended number of frames per second, the game slows down, which is not something I could see anybody wanting.

[bartbes]

You do realize the timer simply cannot be met if the game is too slow?

[Puzzlem00n]

If you used an update time like you are suggesting, that timer would still be using dt, and would still have all of the same problems as dt. The only difference is that you wouldn't have to include dt in your code.

Game Maker uses frames instead of seconds, which is OK, but it means that if the framerate ever drops below the intended number of frames per second, the game slows down, which is not something I could see anybody wanting.

I'm not sure what you mean in that first paragraph. The idea is to have a timer completely independent of framerate. AS3 can do it, and it was written in C++, I believe. If everything updates in the same interval no matter what, everything works at the same speed, and frame updates are updating graphics only rather than ones of math and variable changes.

You do realize the timer simply cannot be met if the game is too slow?

Ah... Now that makes sense. I wonder why Flash is a different situation, then. EDIT: Or is it?

[Inny]

You can replace love.run to implement your own fixed rate timers.

Code: Select all

function love.run()
    local DT = 1.0 / 30 -- 30fps
    if love.load then love.load(arg) end
    while true do
        if love.event then
            love.event.pump()
            for e,a,b,c,d in love.event.poll() do
                if e == "quit" then
                    if not love.quit or not love.quit() then
                        if love.audio then
                            love.audio.stop()
                        end
                        return
                    end
                end
                love.handlers[e](a,b,c,d)
            end
        end
        if love.update then love.update(DT) end
        if love.graphics then
            love.graphics.clear()
            if love.draw then love.draw() end
        end
        if love.timer then love.timer.sleep(DT) end
        if love.graphics then love.graphics.present() end
    end
end

In this example, I've taken the stock love.run and crudely modify the love.timer.sleep line to always sleep 33 miliseconds. However, on most systems, this won't actually sleep 33ms. It'll _try_ 33ms, but will either wake up at 30ms, because of limits to system timers, or stay asleep for many seconds until the system becomes responsive again (because you're also encoding 1080p video, or simulating nuclear reactions).

A more sophisticated timer, like the one in the stock love.run, would accumulate dt's over time and make sure that an average rate of 30hz is occuring, while also throwing out the occasional outliers, so we don't get rapid speed-ups or massive slow-downs.

[Lafolie]

Not to discredit rude and the guys, but 'dt' isn't exactly a special feature that they come up with. There are many applications for it, and personally I think it is quite a clever way to manage frame rates.

Delta Time is used by many games, and I think I'm right in saying that it is especially prevalent in RTS games. I'm pretty sure that some of the more popular frameworks use it too, such as XNA. There's really nothing majorly wrong with it, it solves a huge problem with the tiny inconvenience of multiplying some values by the time it took to calculate a frame.

[Puzzlem00n]

Not to discredit rude and the guys, but 'dt' isn't exactly a special feature that they come up with.

I never really said they came up with it. I was pretty sure other platforms used it, I just wasn't sure of any examples.

In this example, I've taken the stock love.run and crudely modify the love.timer.sleep line to always sleep 33 miliseconds. However, on most systems, this won't actually sleep 33ms. It'll _try_ 33ms, but will either wake up at 30ms, because of limits to system timers, or stay asleep for many seconds until the system becomes responsive again (because you're also encoding 1080p video, or simulating nuclear reactions).

A more sophisticated timer, like the one in the stock love.run, would accumulate dt's over time and make sure that an average rate of 30hz is occuring, while also throwing out the occasional outliers, so we don't get rapid speed-ups or massive slow-downs.

So what you're saying is, I think, that this works, but is susceptible to slowdown mentioned above. You do, however, think that a "more sophisticated timer" could be implemented to throw out outliers? Or are you saying that love already does that? I'm not really sure.

Back to Lafolie:

There are many applications for it, and personally I think it is quite a clever way to manage frame rates.

Delta Time is used by many games, and I think I'm right in saying that it is especially prevalent in RTS games. I'm pretty sure that some of the more popular frameworks use it too, such as XNA. There's really nothing majorly wrong with it, it solves a huge problem with the tiny inconvenience of multiplying some values by the time it took to calculate a frame.

Alright, so maybe it isn't as unnecessarily complex as I'm thinking. I still personally think it would be more convenient to have a timer, but I understand if this doesn't work. I appear, from bartbes's comment, to not have understood the simple notion that framerate is the only updater of everything, and any slower framerate than the time needed will make the timer stall for this reason. I get that now.

[OmarShehata]

This should answer your question very well:

http://www.koonsolo.com/news/dewitters-gameloop/

All the games I've ever done were using a fixed frameRate, so it never needed a dt. Those were all flash games, and the goal was always to optimize so that most computers will be able to run the game at the full speed, and if it lags, then the game is a bit slower. The problem with a fixed frame rate, is as explained in that article, that on slower computers, the game runs slower, and that may break the game (if you have a game that's supposed to be a fast paced shooter or something) it also wastes cpu cycles for computer that are much faster and could potentially run the game at a much higher framerate. There's actually several ways to design your game loop, again, as mentioned in that article.

[Puzzlem00n]

This should answer your question very well:

http://www.koonsolo.com/news/dewitters-gameloop/

All the games I've ever done were using a fixed frameRate, so it never needed a dt. Those were all flash games, and the goal was always to optimize so that most computers will be able to run the game at the full speed, and if it lags, then the game is a bit slower. The problem with a fixed frame rate, is as explained in that article, that on slower computers, the game runs slower, and that may break the game (if you have a game that's supposed to be a fast paced shooter or something) it also wastes cpu cycles for computer that are much faster and could potentially run the game at a much higher framerate. There's actually several ways to design your game loop, again, as mentioned in that article.

Hold on here, a couple of things...

First of all, YOU made Concerned Joe? Dude, you rock! Just saw it in your signature! I played that a long time back. I had no idea you were turning it into a more full release, though. Good job!

As a guy who has a background in flash yet never made anything of note in it (not really anything in love either, unless you count the epic failure that is Empty), I know what you mean. The fixed framerate-style is something I really miss. It's all for the better this way, though, as it seems.

Second, thanks for the article. As it says, I don't think there's any other blog post that talks about these things.

[ivan]

You do realize the timer simply cannot be met if the game is too slow?

Like bartbes said, what would happen if your love.update function takes 0.08 to execute instead of your predefined interval of 0.07? Then your entire game would slow down.

This should answer your question very well:

http://www.koonsolo.com/news/dewitters-gameloop/

Yep, that's the right way to use fixed timesteps (sometimes called 'using an accumulator'). In that case however you may have to update the game state several times per frame and interpolate moving objects based on their angular/linear velocity.
Many people don't realize this, but Box2D was designed to work with a fixed timestep too. For example, some joint types may behave strangely if your delta values vary too much.