Game Development Reference
In-Depth Information
}
return msg.wParam;
}
The
GetMessage()
function will block execution until the application has at least
one message pending, and then it will run the inner block of the
while
loop. This
in turn calls the Windows procedure callback function you registered when creating
the window. If that function blocks the execution of
GetMessage()
by locking the
application in a loop, it won
'
t receive any messages. Have you ever clicked on a Win-
dows program and had it gray itself out, followed by a message saying something like
“
this program is not responding
”
? What
'
s happening is that the program is never
getting back to the
GetMessage()
call.
The problem here is that we can
t stop execution if there are no messages pending,
nor can we ignore messages that come in. The solution here is the
PeekMessage()
function, which is just like
GetMessage()
except that it doesn
'
'
t block execution.
That leaves us with the following loop:
while (msg.message != WM_QUIT)
{
if (PeekMessage( &msg, NULL, 0U, 0U, PM_REMOVE))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
else
{
MainGameLoop();
}
}
This is much better! First, if the application receives a quit message, it breaks out of
the loop. Then it checks to see if there
'
s a Windows message. If there is, it handles it
in the usual way. If not, it allows the game loop to process one iteration.
The code in this chapter is written to integrate with the DirectX Framework, which
handles many nasty problems, such as detecting when a player switches screen reso-
lutions or Alt-tabs to another full-screen application. If you code on other platforms,
you
ll likely be spared these issues. Windows can run multiple applications simulta-
neously, and the user can change hardware configurations, like screen size, while
your game is running. On consoles you can
'
'
t do that, and you avoid all of those hell-
ish little problems.
