Need help :)

[TpOreilly]

Hi, i am following the book called beginning game programming by michael morrision, if any of you's have completed this book could you please help me out. Im confused with this bit of code:

while (TRUE)
    {
      if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
      {
        // Process the message
        if (msg.message == WM_QUIT)
          break;
        TranslateMessage(&msg);
        DispatchMessage(&msg);
      }
      else
      {
        // Make sure the game engine isn't sleeping
        if (!GameEngine::GetEngine()->GetSleep())
        {
          // Check the tick count to see if a game cycle has elapsed
          iTickCount = GetTickCount();
          if (iTickCount > iTickTrigger)
          {
            iTickTrigger = iTickCount +
              GameEngine::GetEngine()->GetFrameDelay();
            GameCycle();
          }
        }
      }
    }

Im stuck on the else bit.

I understand that the else part will be carried out if PeekMessage returns false (if it receives no messages).

Now, the GameCycle() function is there to update things like sprites every frame.

My question is, im not sure why we only call the GameCycle() function when PeekMessage returns false, because wouldnt we want it to update graphics whist it IS receiving messages?

[hanst99]

That's your game logic. That else part is supposed to be executed when your program doesn't have anything else it needs to take care of (like proccessing key input or stuff like that) - but that's why I keep saying games are not good to get started with programming, beginners usually don't understand the logic behind games...

[TpOreilly]

Ok, thanks.

Could you explain this to me:

When my program has several messages it needs to process, wouldnt that make the games graphics freeze as it would stop updating the graphics.

I think i know the answer to this question myself, but i just like to make sure :D

[hanst99]

Yes of course. But the procession of messages happens way too fast for a human to notice (usually anyways). In fact, drawing graphics usually takes quite a bit longer than other stuff (e.g. moving an object), which is why you want to prevent the graphics from updating too often for the sake of having a stable game logic.

But of course it also depends on where you actually draw your graphics - do you do that in your game cycle, or when you process WM_PAINT?

[TpOreilly]

WM_PAINT draws the graphics, GameCycle updates them.

[TpOreilly]

The thing im finding hard to imagine is what if a game has ALOT of messages to process, like some big games do, and it dont give itself a chance to update its graphics?

[hanst99]

The messages that you get with PeekMessage are windows messages - and windows doesn't care about the size of your project. A hello world windows application receives the same amount of messages like a commercial game.

And don't underestimate your PC, PC's are actually quite fast.

[TpOreilly]

Ok, so the GameCycle() function will always be called every X amount of frames?, even if the program has to process alot of messages because the messages are processed extremely fast?

[hanst99]

will always be called every X amount of frames?

Not necessarily, but it is very likely. Of course you are right that with this design, it's theoretically possible for the program to get locked. You usually have a backup kinda thingy that forces an update though.

You gotta think about what messages CAN be send, like mouse moves, mouse clicks, button presses, timer messages, paint messages etc... most of those don't get sent very often in the first place.

[TpOreilly]

OK :) Can you tell me what is going on when we process the WM_PAINT message:

switch (msg)
  {  

      case WM_PAINT:

         HDC         hDC;
         PAINTSTRUCT ps;
         hDC = BeginPaint(hWindow, &ps);

         // Paint the game
         GamePaint(hDC);

         EndPaint(hWindow, &ps);
         return 0;

:)

[hanst99]

Tp... seriously, put that book away and learn to program with something else before you start reading it again. You can't come here asking for help for every little thing, you'll never learn anything like this.