Programming Role Playing Games with DirectX Book

Started by
4 comments, last by _chasers 21 years, 8 months ago
I''m new at both Windows and game programming so I might be misunderstanding something here regarding the basic application framework. In chapter 5 of the book "Programming Role Playing Games with DirectX" (p.150) in the WinMain() function, there is an if...else statement within the main while loop. It says (this is not word for word, I shortened the "else" part for simplicity): if(PeekMessage(&Msg, NULL, 0, 0, PM_REMOVE)) { TranslateMessage(&Msg); DispatchMessage(&Msg); } else { // do game processing } So what happens here if the user continuously moves his/her mouse around and keeps sending Windows messages? Then peek message will never be false and the game processing section will never be reached until events stop being sent to the message queue. In "Tricks of the Windows Game Programming Gurus (2nd Ed)" chapter 4 page 205, the code structure looks pretty much the same EXCEPT that there is only the IF statement and no ELSE statement. That way even if there are windows messages, the game processing code still gets executed. Are my assumptions correct or am I misunderstanding something here? Which is the correct way to do it? Or do both ways work fine? Thanks
Advertisement
I''m going to take a stab at this and say that even if you are constantly moving your mouse, or doing anything else, doesn''t mean that there will always be messages being sent to your app. Remember just because your game is the only application running doesn''t mean that it is the only PROCESS running.

So I think both loops will work the same way. They are both going to process their messages while there are any in their local queue. The total processing time will probably only be a few ms even if you are constantly moving your mouse. Once windows stops sending your process messages and moves on the the next process is when your game will do all of its stuff. Sorry if I got it wrong or confused you more. I''m still a beginner too.

Take a look at Tricks on page 52-53 for some figures and a better explanaition.

p.s. excuse me english. im from L.A.
**DrunkenBastard puts on a bunny suit and beats you to death with a metal dildo**
I''m not even sure that windows sends a message if the mouse is moved. That''s for you to determine by polling the mouse every frame. Anyway, I use the method you posted, and it works fine. I guess windows sends messages so infrequently that the drop in frame rate is unnoticable. Doing it the other way may be better, as long as you make sure not to do anything silly like running the game code after recieving a destroy message and shutting down.
Tolerance is a drug. Sycophancy is a disease.
DrunkenBastard is right, even if you continuously move the mouse, you cannot generate enough messages to stop the else code from executing. However, I still prefer the method without the else. If there is ever a time when there are a ton of messages being genereated, then code without the else will be more robust. And since it appears to work the same most of the time, it does not hurt to remove the else.

fishyeyel83l: I guess you don''t do much Windows programming. No offence intended, but Windows generates messages for everything, including mouse movement and buttons.

---
Make it work.
Make it fast.

"I’m happy to share what I can, because I’m in it for the love of programming. The Ferraris are just gravy, honest!" --John Carmack: Forward to Graphics Programming Black Book
"None of us learn in a vacuum; we all stand on the shoulders of giants such as Wirth and Knuth and thousands of others. Lend your shoulders to building the future!" - Michael Abrash[JavaGaming.org][The Java Tutorial][Slick][LWJGL][LWJGL Tutorials for NeHe][LWJGL Wiki][jMonkey Engine]
Thanks for the replies everyone. Yeah, I think I''ll just use the code without the else statement to be safe.
I'm currently using the even-more-disgusting version


      while( running ){  while( PeekMessage( ..., PM_REMOVE ) )  {     // Message Processing, just queues parsed messages for logic  }  gameLoop.Tick();  // Handles logic/messages, and then renders.}  


And even Tick() isn't guaranteed to actually render anything, it just comes back if no time is left over to render.

I haven't stress-tested this yet though.. Will do soon enough, when the framework is complete. The idea is simple: empty the windows message queue, therefore making sure that before we do anything at all, we know exactly what the user wants to do.
Then, when the message queue is empty (and there are some VERY big "watch outs" there, particularly the WM_PAINT message), start processing the messages, updating the game logic.
Then, if any time is left over, do the actual rendering


[edited by - MadKeithV on August 12, 2002 7:53:13 AM]
It's only funny 'till someone gets hurt.And then it's just hilarious.Unless it's you.

This topic is closed to new replies.

Advertisement