7.3. Game Loop Architectural Styles 307
7.3. Game Loop Architectural Styles
Game loops can be implemented in a number of diff erent ways—but at their
core, they usually boil down to one or more simple loops, with various embel-
lishments. We’ll explore a few of the more common architectures below.
7.3.1. Windows Message Pumps
On a Windows platform, games need to service messages from the Windows
operating system in addition to servicing the various subsystems in the game
engine itself. Windows games therefore contain a chunk of code known as a
message pump. The basic idea is to service Windows messages whenever they
arrive and to service the game engine only when no Windows messages are
pending. A message pump typically looks something like this:
while (true)
{
// Service any and all pending Windows messages.MSG msg;
while (PeekMessage(&msg, NULL, 0, 0) > 0)
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
// No more Windows messages to process – run one
// iteration of our "real" game loop.
RunOneIterationOfGameLoop();}One of the side-eff ects of implementing the game loop like this is that Win-
dows messages take precedence over rendering and simulating the game. As
a result, the game will temporarily freeze whenever you resize or drag the
game’s window around on the desktop.
7.3.2. Callback-Driven Frameworks
Most game engine subsystems and third-party game middleware packages
are structured as libraries. A library is a suite of functions and/or classes that