Game loop on windows

I have not seen an else being used in this instance (the Rastertek tutorial you mentioned does not use an else).

My guess would be if that you tried to resize your window the game rendering would freeze proving that the else part is never executed, as the resize message would be constantly sent.

A common loop would have this structure.

while (true) 
{
    while (PeekMessage(&msg,0,0,0,PM_REMOVE)
    {
        // Translate and dispatch message
    }

    if (msg.message == WM_QUIT)
    {
        break;
    }

   // Do update, rendering and all the real game loop stuff

}

I think the thing you need to grasp is that the message processing will run much faster than the rate at which messages are sent.

For the example code you've provided, here's an estimate of timings:

while (msg != WM_QUIT) // 
{
    if (PeekMessage(&msg,0,0,0,PM_REMOVE)
    {
        // Translate and dispatch message
        // [A] --> This takes a very small amount of time (epsilon ms)
    }
    else
    {
        // Do update, rendering and all the real game loop stuff
        // [B] --> This takes way more time, ~16 ms at 60 fps for instance
    }
}

I've not searched the documentation for this but Windows is probably not spamming messages all the time: they have to come at regular intervals or they'd be clobbering the system. Maybe they use the keyboard refresh rate if you keep pressing one key. Maybe they use the screen refresh rate.

Let's say a new message comes every t ms, reasonably greater than epsilon. The [A] part of the loop will process all stacked messages very quickly: it will run for epsilon ms and start again, which leaves no chance for new messages to arrive. As soon as all messages are consumed, the [B] part will run and new messages will stack again.

Here's an illustration to try to make my point, [An] are processings of the [Mn] messages sent by Windows, and [Bn] are actual frame updates:

Game:    --[A1][B1----------][A2][A3][A4][B2----------][A5][A6][A7][B3------->

            ^       ^       ^       ^       ^       ^       ^      ^      
Windows: ..[M1]....[M2]....[M3]....[M4]....[M5]....[M6]....[M7]....[M8]....

Here you can see that as long the duration of [A] stays reasonably small compared to the message rate (it's already very exaggerated here), the game will still have plenty of time to update its frames.

So this explains why such a game loop structure doesn't prevent a game to run normally. But the solution CoderScott proposed in his answer makes this execution flow much more explicit, so in my opinion it should be preferred.

if/else in your loop will process windows messages before anything. It will not block loop too long (of course if your WndProc will be good). Usually there is not so much messages. I dont think there is a better way to prevent window from stop responding and save FPS. If you will keep your message processing code good i think your loop will be great.

Here is my code, i believe it will be interesting for you, and it is quite usable. But one day i will code a new one. At least it is much better than many other. For playable game you will definitely need a stable state update() rate. Windows messages will not break it.

// Game loop paramters.
const int TICKS_PER_SECOND = 70; // Update() rate per second
const int SKIP_TICKS = 1000 / TICKS_PER_SECOND;
const int MAX_FRAMESKIP = 10;

Run() function:

DWORD next_game_tick = GetTickCount();
int loops;
MSG msg = {0};
m_bIsGameRunning = true;
while( msg.message != WM_QUIT && m_bIsGameRunning )
{
    if( PeekMessage( &msg, NULL, 0, 0, PM_REMOVE ) )
        g_pWindow->HandleMessage(msg); // translate and dispatch the message
    else
    {
        // *Update*
        loops = 0;
        while( GetTickCount() > next_game_tick && loops < MAX_FRAMESKIP)
        {
            Update();

            next_game_tick += SKIP_TICKS;
            loops++;
        }

        // *Draw*
        Render();
    }
}
m_bIsGameRunning = false;