RE: The Game Loop

Hello Reader,

Check out this great article about game loops.The article is great, and explains some of the most popular methods ofseparating parts of your game logic to allow different parts of yourgame to update with different frequencies. However, the article'sconclusion is a bad idea, and furthermore, the author thinks that notusing 100% CPU is sin itself.

1) Unused cpu is NOT wasted.

It is trivial to set a thread's priority to realtime on Win32, and thencall sleep with the precise number of milliseconds that the game hasnothing to do until the next update. At least on WinXP, this results inmy game taking up only 20-85% of CPU and allowing other stuff to runsmoothly in the background.

2) Base your game loop timings closely with your physics.

a) Nearly all games use physics engines.
b) Higher frequency = less tunnelling (Tunnelling in game physics iswhen updates are infrequent enough that a small, fast moving objectmoves from one side of an object in a single update, most physicsengines won't detect a collision!)
c) Double the updates isn't twice as expensive, because some physicsengines' update cost is linearly corrolated to the number of collisionsthat are detected. More updates with smaller time deltas = lesscollisions per update.
d) The fixed cost of a physics engine's update is often reduced by aggressive caching, spatial coherence graphs, ect.
e) The caching mechanisms in most physics engines break if the physics is not given fixed timesteps.

The author of that article suggested that displayshould use interpolation in order to maximize use of extra possibledisplay frames, so that faster computers have a smoother lookingdisplay. However, I think that he was imagining that a game's updateloop was running between 25-100 times each second. Carrot Run's physicsare updated 900 times each second.In such a scenario where the physics runsso frequently, we are guaranteed that no two vsync'ed frames willdisplay the same view, since most displays cannot refresh faster than120 times each second.

Icould easily disconnect the game object logic from the physics sothat the game object logic is either only triggered to run when acollision occurs, or when a 1/25th of a second has passed, but for nowperformance isn't a problem. If I had a very expensive to run AI, andthe AIwas stable at 5Hz, and a particular user's machine was too fast, Iwould just run the AI at a higher frequency for them. Unlike physics,AI is more resiliant to time step changes, and could produce slightlybetter results with more CPU. Why complicate the display routines?Furthermore, I do know people who like to play games while theirmachine is churning away on other tasks. If the game is trying to take100% CPU for no additional benefit, large network file transfers orother batch processes will crawl.