Game Development Reference
In-Depth Information
something that will work on many platforms. If a game view returns
true
from
VOnMsgProc()
, it means that it has completely consumed the message, and no
other view should see it.
This architecture will still work with a multiple player, split-screen type of game
—
here
s how. The
HumanView
class can contain multiple screens, but instead of being
layered, they will sit side by side. The
HumanView
class will still grab input from all
the devices and translate it into game commands, just as you are about to see, but in
this case, each device will be treated as input for a different player.
Back to the implementation of
HumanView::VOnMsgProc()
. Its job is to iterate
through the list of screens attached to it, forward the message on to the visible
ones, and if they don
'
t eat the message, then ask the pointer and keyboard handler
if they can consume it.
'
LRESULT CALLBACK HumanView::VOnMsgProc( AppMsg msg )
{
// Iterate through the screen layers first
// In reverse order since we
'
ll send input messages to the
// screen on top
for(ScreenElementList::reverse_iterator i=m_ScreenElements.rbegin();
i!=m_ScreenElements.rend(); ++i)
{
if ( (*i)->VIsVisible() )
{
if ( (*i)->VOnMsgProc( msg ) )
{
return 1;
}
}
}
LRESULT result = 0;
switch (msg.m_uMsg)
{
case WM_KEYDOWN:
if (m_KeyboardHandler)
{
result = m_KeyboardHandler->VOnKeyDown(
static_cast<const BYTE>(msg.m_wParam));
}
break;
case WM_KEYUP:
if (m_KeyboardHandler)
