Double buffering is the best bet.....
Also look at the OnEraseBkgnd() handler (and return 0)
MFC is not that good for games due to the way it retrieves messages from the OS. Games update while there are no msg's.
Look at 'Idle Loop Processing' in MSDN
OnIdle() allows you to add functionality to the app when there are no msg's from the OS. But should not be used for lengthy operations.
this is the MFC message loop
Code:
for (;;)
{
// phase1: check to see if we can do idle work
while (bIdle &&
!::PeekMessage(&m_msgCur, NULL, NULL, NULL, PM_NOREMOVE))
{
// call OnIdle while in bIdle state
if (!OnIdle(lIdleCount++))
bIdle = FALSE; // assume "no idle" state
}
// phase2: pump messages while available
do
{
// pump message, but quit on WM_QUIT
if (!PumpMessage())
return ExitInstance();
// reset "no idle" state after pumping "normal" message
if (IsIdleMessage(&m_msgCur))
{
bIdle = TRUE;
lIdleCount = 0;
}
} while (::PeekMessage(&m_msgCur, NULL, NULL, NULL, PM_NOREMOVE));
}
This is slow as PumpMessage() calls GetMessage() which is additional overhead as msg has already been 'found' with PeekMessage().
Compare this to a game loop
Code:
MSG msg;
// prime loop
PeekMessage( &msg, NULL, 0, 0, PM_NOREMOVE);
// run till user exits
while (msg.message!=WM_QUIT)
{
//use peek as it returns immediately
if (PeekMessage( &msg, NULL, 0, 0, PM_REMOVE))
{
// dispatch the message
TranslateMessage(&msg);
DispatchMessage(&msg);
}
else
{
// update and redraw screen
}