What are the pros and cons of a non-fixed-interval update loop?

Question

I am studying various approaches to implementing a game loop, and I have found this article.

In the article, the author implements a loop which, if the processing falls behind in time, skips frame renderings and just updates the game in a loop (the last variant called "Constant Game Speed independent of Variable FPS").

I do not understand why it is acceptable to call update_game() in a loop without making sure the update function is called at a particular interval. I do not see any value in doing this. I would think that, in my game, I would want to be sure that the game is updated periodically with a known period.

Maybe it is worthwhile to have two threads, where one would call the update function, periodically, and the other one would redraw the game, also periodically. Of course, I would need to synchronise the threads. Would this be a good and practical approach?

Answer 1

The reason is without custom hardware there is no way to be absolutely sure that the function is called at the exact same interval each time. If it's a PC game, what happens if someone has a slower computer than you expected? Or a faster computer than you expected? Or just Alt-tabbed? If it's a phone game, what happens when a new version of the OS comes out? etc...

Instead you follow the guidelines there, determine a target frame rate, if you've fallen behind update now, if you're ahead, sleep until the targeted frame rate is reached. The update functions take a delta time so that you can interpolate between the desired time and the actual time.

Answer 2

Well, generally things are time sensitive in games, not frame sensitive, so, update is called as often as possible to make sure better (more frequent) times can be achieved. however, the draw call is generally at a specific interval. And, generally games (more complex ones) use threading for specific tasks like managing physics, etc. However, you could have a specific render thread just so the game doesn't lock up. Also, some games do have a fixed/locked timestep for update, but its not required.

Answer 3

This distinction can be based on a lot of factors.

How is your physics going to function? will it be based on a variable frame rate for smoothness to the frames, or will it be based on a fixed frame rate for accuracy of calculations.

How complex will your collision system be, or how many objects might be colliding each frame? (this can be a major bottle neck for variable frame rate let alone bottle neck period)

variable frame rate is the easiest (assuming that your keeping a clock to give to physics, and maybe collisions) in that you just have a loop with a defined break on exit command

for a constant frame rate I have seen, and done it a few different ways.

1. have the same loop as a variable frame rate, and just don't enter it until a minimum amount of time has passed.
2. have a threaded system with physics working on its own, but only wake the physics thread at given increments.

though I would have to mention that if you want a fixed frame rate have some debug write displaying the frame rate to make sure that your not getting to low of a rate. (then start optimizing), and realistically test your game on more then just one system even if you have min requirements.