3 ms·
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 developmen
by koonsolo 8y ago
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.
- vectorrain 8y agoWhen I google "game loop"， I found deWiTTERS Game Loop, http://www.koonsolo.com/news/dewitters-gameloop/ http://www.koonsolo.com/news/dewitters-gameloop/ which I still not fully understand.
- koonsolo 8y agoWhat is the part that is not clear?
- vectorrain 8y agoThe 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()".
- koonsolo 8y agodisplay_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 ...
- vectorrain 8y agoFair 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.
- cjsawyer 8y agoEvery 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.
- exlurker 8y agoThank you for this article, it really helped me out several times :)