News for hackers. Stuff that matters.
Re:Game Loop by koonsolo on Sunday January 27, 2019 @12:43AM (#19010498)
I have a funny story about the deWiTTERS game loop that I wrote a long time ago (referred to in the article above)

Back then I was doing mobile game development for PocketPC.

After I left that company, some ex-colleague had to do some changes in my code, or port it, I can't remember. So he was looking at that game loop that I implemented, and was thinking "What the hell is he doing here???". So he did a google search to see if he could find something, and immediately stumbled upon an article, written by that same programmer :D.

He told me years later when I saw him, and said "What are the chances that you search something on google because of code you're going through, and find the article that explains it written by the same programmer".

I was still a junior back then, so probably I should have commented my code a bit better (instead of not at all ;)).

I still want to write a revised deWiTTERS game loop article, because the steps in a physics engine could make the extrapolation redundant.

Re:Game Loop by vectorrain on Sunday January 27, 2019 @12:54AM (#19010529)
When I google "game loop", I found deWiTTERS Game Loop, http://www.koonsolo.com/news/dewitters-gameloop/ which I still not fully understand.
Re:Game Loop by koonsolo on Sunday January 27, 2019 @12:58AM (#19010537)
What is the part that is not clear?
Re:Game Loop by vectorrain on Sunday January 27, 2019 @01:15AM (#19010570)
The sconed part "Game Speed dependent on Variable FPS". I'm confused about the parameter of function "update_game()". From the code, I think the time length of "curr_frame_tick - prev_frame_tick" would increase at each timestep beacause of function "display_game()".
Re:Game Loop by cjsawyer on Sunday January 27, 2019 @03:33AM (#19010910)
Every loop, prev_frame_tick is assigned the old value of curr_frame_tick before curr_frame_tick is updated. That means the value of their difference is the time in ticks it took for the last loop to execute. That difference is used to scale things like physics.

As an example, if we want to move something on screen at a constant rate in pixels per second, the number of pixels to move per update (ie frame) at 60 FPS is half as far as when updating at 30 FPS. The result is that the position at any time is the same regardless of how quickly the computer ran the simulation.

Re:Game Loop by koonsolo on Sunday January 27, 2019 @03:25AM (#19010888)
display_game() doesn't change any of these values.

(curr_frame_tick - prev_frame_tick) is the delta time of each loop. So this value is the time it took to do the previous loop.

It doesn't increase each timestep because prev_game_tick is recalculated each step.

Step1 (initial step):

- prev_frame_tick = 0

- curr_frame_tick = 0

- delta = 0

Step2:

- prev_frame_tick = 0

- curr_frame_tick = 200

- delta = 200

Step3:

- prev_frame_tick = 200

- curr_frame_tick = 356

- delta = 156

...

Re:Game Loop by vectorrain on Sunday January 27, 2019 @04:55AM (#19011116)
Fair enough. I think I didn't understand the difference between game time and real time before. I though the running time of "display_game()" was the game time (curr_frame_tick - prev_frame_tick). Thanks a lot for your detailed explanation.
Re:Game Loop by exlurker on Sunday January 27, 2019 @09:35AM (#19011832)
Thank you for this article, it really helped me out several times :)