What I am asking is don't these non changing definitions inside a running loop consume extra cpu time? Or does the computer somehow know it only needs to deal with them once even though they are declared in this constantly running body of code?

Actually you should clear the render target everytime before you draw something on its buffer, but that doesn't mean that's the only way do that it is to create a bgColor variable inside the function.

This is simply not true, if you know that all the geometry in your scene is going to cover the whole back buffer than not clearing the back buffer saves quite a bit of time, and this is general practice in games. In debug builds its often a good idea to actually use alternating colors, and clearing in generally, this will catch not covering the whole buffer fast.

Generally the compiler will optimise this stuff away anyway in a release build, it will most likely see that it can directly pass the arguments to the Clear call. These things are micro optimisations to start writing this different. Its a lot clearer if the code is written like you have presented it and letting the compiler figure out how it can do those 3-4 lines faster.

You're correct NightCreature. My intention was saying to clear before rendering the entire scene in the most simpler case. If he draws everytime he would be seeing only the last object being rendered. Thanks for correcting.

That is also not what I am saying, I am actually saying that you dont need the clear at all, if you know that what you are about to render will cover the entire back buffer then not doing the clear will be faster. And this can be done in multiple calls.

Don't if-else your windows messages like that.

I think you misread his code, because it definitely consumes all messages before rendering.

No he doesn't. He peeks one message, then renders, then peeks another, then renders. Look again. There is an outer while loop, then an if-else inside it.

    while( WM_QUIT != msg.message )
    {
        if( PeekMessage( &msg, nullptr, 0, 0, PM_REMOVE ) )
        {
            TranslateMessage( &msg );
            DispatchMessage( &msg );
        }
        else
        {
            Render();
        }
    }

What do you think happens if there are three messages in the queue at the start here?

Message

Render
Message

Render

Message

Render

it definitely consumes all messages before rendering.

Yeah, it does. I.e., it can be read as:

A:
If ( there's a message ) process it; // N.B., PeekMessage returns TRUE if there's a message
Else Render;
If (WM_QUIT != message ) goto A;

Aardvajk's loop works also, except it should contain a "courtesy" test to avoid rendering when the user has already asked it to stop:

if( WM_QUIT != message) Render();

He peeks one message, then renders, then peeks another, then renders. Look again.

Not quite.

Since PeekMessage returns non-zero if there is a message, only the if part will execute each iteration of the while loop, until there are no more messages. At that point, the else part will execute.

That said, I personally prefer the way you wrote it myself, but the way it is posted does consume all messages between each render.

He peeks one message, then renders, then peeks another, then renders. Look again.

Not quite.

Since PeekMessage returns non-zero if there is a message, only the if part will execute each iteration of the while loop, until there are no more messages. At that point, the else part will execute.

That said, I personally prefer the way you wrote it myself, but the way it is posted does consume all messages between each render.

Oops, sorry, yes, quite right. My mistake. Sorry Mona2000 and thanks for clarifying.