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

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?

• I'm not sure I agree with the idea of throttling an application to be consistent with a wide range of hardware. I think it's better to determine a target minimum hardware spec, build for that target and optimize as much as possible. – Chuck D Apr 1 '12 at 1:46
• if your going to disjoint physics from graphics then you better make sure that collision resolution is done before you render. because the order of bottle necks goes collisions, physics, graphics, and then maybe AI depending on complexity. though this list may vary slightly from game to game – gardian06 Apr 1 '12 at 8:33

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.

• Thank you. RE: "the update functions take a delta time". I would think that it is necessary to pass a time delta, yes, but the code in the article calls update_game() without any parameters. Instead it passes something similar to this time delta to the display_game() function. This is confusing. – akonsu Apr 1 '12 at 1:49
• @akonsu the update_game() is being done at fixed intervals for accuracy of calculations, and the display_game() is being done every time it is reached to match the speed of the system calling it. if your physics needs time then just feed it the frame length no big deal really just takes a few extra processes for data passing, or you can re-write your physics with a const value. though sense the article doesn't reference what all is going on in the update_game() it is difficult to tell for sure. – gardian06 Apr 1 '12 at 22:02

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.

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.