Game Development Reference
In-Depth Information
Multithreaded Game Loops
Although many mobile and independent titles still use a variant of the traditional
game loop, most AAA console and PC titles do not. That's because newer hard-
ware features CPUs that have multiple cores. This means the CPU is physically
capable of running multiple lines of execution, or
threads
, at the same time.
All of the major consoles, most new PCs, and even some mobile devices now fea-
ture multicore CPUs. In order to achieve maximum performance on such systems,
the game loop should be designed to harness all available cores. Several differ-
ent methods take advantage of multiple cores, but most are well beyond the scope
of this topic. However, multithreaded programming is something that has become
prevalent in video games, so it bears mentioning at least one basic multithreaded
game loop technique.
Rendering graphics is an extremely time-consuming operation for AAA games.
There are numerous steps in the rendering pipeline, and the amount of data that
needstobeprocessedisrathermassive; someconsolegamesnowrenderwellover
a million polygons per frame. Suppose it takes 30 milliseconds to render the entire
scene for a particular game. It also takes an additional 20 milliseconds to perform
the game world update. If this is all running on a single thread, it will take a total
of 50 milliseconds to complete a frame, which will result in an unacceptably low
20 FPS. But if the rendering and world update could be completed in parallel, it
would only take 30 milliseconds to complete a frame, which means that a 30 FPS
target can be achieved.
In order for this to work, the main game loop thread must be changed so it pro-
cesses all inputs, updates the game world, and outputs anything other than the
graphics. It then must hand off any relevant data to a secondary rendering thread,
which can then draw all the graphics.
But there is a catch to this: What should the main thread do while the rendering
thread is drawing? We don't want it to simply wait for the drawing to finish, be-
cause that would be no faster than performing all the actions on one thread. The
way this problem is solved is by having the rendering thread always lag one frame
behind the main thread. So every frame, the main thread is updating the world
while the rendering thread draws the results of the last main thread update.
One big drawback of this delay is an increase of
input lag
, or how long it takes
for a player's action to be visible onscreen. Suppose the “jump” button is pressed
during frame 2. In the multithreaded loop, the input will not get processed until the
