Well, I'd say if you check for closing once every frame that would be quite enough for the player to think the game stopped right the same instant he/she pressed the quit button. And if we take a close look at Magmai's code we'll see that he gives the thread 5 seconds to quit nicely and after that he kills it. If it takes 5 seconds then something is probably wrong (unless your close-down code takes forever).
Some problems with the ProcessMessage() (depending of how it is implemented):
If ProcessMessage() process only 1 message each time it's called the message queue could be flooded by messages in the worst case (many messages sent, framerate low).
Else if ProcessMessage() processes all messages each time, it could decrease, or worse, give huge differences in framerate, which would make the game seem choppy in the worst case (bursts of messages distributed unevenly).
So the best thing (in your case) would be to process a constant amount of messages each frame (probably more than 1).

Edited by - amag on February 26, 2001 8:12:27 AM

If a flood of messages is sent, there''s nothing you can really do about it. It''s quite common in even professional games these days for the game to drop a few FPS for a moment. Not that you should be receiving that many messages normally anyway. With your suggestion, you could stretch it out, but that would only distribute the FPS loss over several frames. If you were using the multithreading code, then all the messages would be processed at once...

The purpose of trying to code in ol'' dos style, is so that, for example, in an rpg, you could have a function to display a series of text messages in a series of boxes, and the function only returns when the box has been closed. Now for long text messages, that could take quite a length of time - and it is not uncommon for text messages to go for longer than five seconds. Let''s say the gamer is living with his parents. He has ust started a lengthy conversation with an NPC, when his parents call him to dinner. He presses alt-F4. He waits for the damn thing to shut down. Get the idea?

In a simple 2d game I''m working on, I have included message handling in a function merely called "Sync()". This updates some keyboard-related flags, handles messages, waits for a vertical blank, and flips the buffers. I also use a macro, SYNC, defined as "if(!Sync()) return false". The rest of the return value chains are manual, but the functions don''t run very deep, and there aren''t many of them. Macros help out, though.

quote:
First of all calling WaitForXXX() can cost up to 400 CPU cycles as it transitions to kernel mode and back. That''s a good way to lower your framerate, especially if you are calling WaitForXXX each frame!

Hm, let''s do a calculation: 400 CPU cycles, and on a reasonable low-end (of todays standard) computer, a PII 400 Mhz, will 400 cycles take appr. 1us (since 1 cycle/s == 1 hz, thus the above computer would be capable of 400M=400*10^6 cycles per second). Do you really expect 1us per frame (saying we display 60 frames per second) will decrease the framerate noticably? I don''t think so.
This is what pre-mature optimisation means, optimising on the wrong places, just because you believe it is slow.

Beer Hunter:
What you don''t seem to realise is that an even frame-rate (although low) is much prettier than a jumpy one. It''s far better to have an even 30fps than to have 60 that drops to 40 every once in a while, since the drop in frame-rate is much more disturbing and noticeable.
If I was to use multi-threaded code the message-pump thread would have it''s time-share of the CPU-time to process messages, so to that thread it will look like it processes all messages at once, but it will be interrupted by other threads (or rather the scheduler), so it would probably be a smoother way.
And about that boy, does he really have to wait for the program to close down ? Besides it''s pretty easy to say that the lengthy conversation should be ended if the player quit''s, even if you use threads.