Wrong use of delta time

[bseto]

commit 632ecfd:

This is not the proper way to use delta time. This is trying to sync the game into only going 50times a second. When you get more and more objects on the screen, and the computer cannot keep up the 50 times a second then you are in trouble.

The proper way to use delta time is to multiply delta time with all your movement velocities in the game. If your game is updating 100fps, then your delta time is small, and so every frame will be velocity x (small delta_time However, if your game is updating at 10fps, delta time is large and every frame will be velocity x (large delta_time).

When you use delta time in the above way, the distance travelled will not change regardless of your framerate.

[enochtsang]

Glad you're actually reading through my work, I thought you'd comment on this haha.

One disclaimer that I want to say is that I didn't expect this to be the correct way of doing things, I implemented this so I could get going on other things.

That said, I disagree with my approach due to the problem you've suggested but I also disagree with your solution because it creates a residual lag issue. I was reading from http://gameprogrammingpatterns.com/game-loop.html, if you go to "How do you control gameplay speed" it shows both our solutions. Mine is "Fixed time step with synchronization", yours is "Variable time step". In a nutshell, the problem with the solution you've suggested is it causes residual lag that builds up varying on the computer (read the paragraph in the book, my solution is ass). If we were thinking of keeping this game single player, I would be fine with it. But because there are hopes of making it multiplayer in the future, I think the residual lag build up will cause a serious issue.

We should be implementing the fourth solution, but I think because the prototype will be fairly simple, we can stick with the current game loop I have right now (due to it's simplicity). Our prototype shouldn't be less than the ~50fps I've set it as.

[bseto]

I read the article on residual lag. This won't happen because everytime you render, you update.

I was also thinking maybe you took this approach because its just a prototype so ya we can keep it like this or maybe I'll make a pull request with a change later.

But for the actual thing, this is the way you would do it in games. The setup you have with calling update() on the mainloop and then having it cascade all the way down I think is good. Only thing you'd change to add deltatime to your implementation is by adding an argument to update() which accepts deltatime. So everytime you call update(), all your positions are calculated according to delta time, and then you draw().

https://github.com/Mekire/pygame-delta-time/blob/master/dt_example.py Has a good example on line 110 and line 58.

EDIT:

k but rip, apparently it is a hard thing to do correctly. http://gamedev.stackexchange.com/questions/1589/when-should-i-use-a-fixed-or-variable-time-step

[enochtsang]

Ok, I'll talk a look at implementing this change tonight, I'm writing up a targeting system framework at the moment.

[bseto]

http://gamedev.stackexchange.com/a/2844 (Guy is advertising a more fixed time solution hybrid)

Actually. I think I like this guy's answer. I'd also actually rather see things start moving slower rather than missing frames and losing character control. He said this specifically for Arcade style games (Which is ours, we will definitely need character control (typing control))

But then there's the argument of cheating when someones using a stupidly slow computer.

[bseto]

Current usage of delta time is intentional. Closing issue.