Comparing Game Loops

Started by
2 comments, last by SimmerD 18 years, 8 months ago
Hi im looking into the different types of game loops and was wondering of the pros and cons of each. as far as iunderstand it there are two basic types - constant frame rate - variable frame rate by constant i mean that an if statement checks if the required time period has elapsed before procedding to make another frame. by variable i mean that the loop runs as fast as possible and passes the elapsed time to each subsystem and they factor it into calculations. Is this basically right, im i right in thinking that a constant frame rate is limiting?
Advertisement
Constant framerate
A constant framerate is quite manageable, is perfectly smooth if the system has enough processing power to reach that framerate. Otherwise, it slows down. Because of the constant timestep, physics are also easier to do. A constant framerate also is a bit more friendly to other tasks on most multitasking OSes.

Variable framerate
A variable framerate has the advantage that if the PC has more processing power, the game becomes smoother. It is also more playable if the system doesn't have enough power to make the constant framerate since it doesn't slow down, just gets choppier. If the framerate varies too much, though, this can be a distraction to the player. If you link your physics to the framerate, this can also blow up in case the timestep is too large.
Kippesoep
I believe the distinction is not that explicit. The game loops themselves can remain quite the same but one of them skips frames every now and then. Moreover the simulation time does not have to be linked to the frame rate (as Kippesoep said somehow). If I were to dichotomize game loops I'd rather go with multi-threaded/single-threaded or passive/active (or something; read it recently somewhere) because these things make much more of a difference.

Greetz,

Illco
If you are doing any sort of detailed physics, I'd recommend doing the game logic at a fixed rate, and the rendering at a variable rate.

It's also a nice way to force you to de-couple the rendering from the gameplay code.

This topic is closed to new replies.

Advertisement