I know two different approaches to implement a basic game template: 1st the Andre LaMothe Style (I call it that way since i know it from his book "Windows Game Programming for Dummies"), using three functions placed around the Windows Message Pump:

GameInit(); // Initialize the Game while( 1 ) { if( PeekMessage( &msg, NULL, 0, 0, PM_NOREMOVE ) ) { if( !GetMessage( &msg, NULL, 0, 0 ) ) { return msg.wParam; } TranslateMessage(&msg); DispatchMessage(&msg); } else GameUpdate(); // Run the Game } GameQuit(); // Finish it.

The 2nd approach is using an additional thread for your game-loop, running besides the initial Windows thead, as described in the article "Getting Rid of the Windows Message Pump" Well, i''m really interested how you implement that bit of code

In my opinion, using a seperate thread is a very messy way of doing it. With the first method you described, it is also possible to get into a mess, but only if you don''t think about what you are doing. If you design your code wisely you will have no problems.
You might also want to consider being able to port your code to a system which can''t handle multiple threads.

I use Andre''s game loop. I don''t see any real performance increase from threading the main loop. I reserve threading for game objects only. The last thing I need is to have to manage a project where the architecture itself is spread out in threads along with the game objects! Ugh, I just got a headache, I ahve to sit down....

==============================
"Need more eeenput..."
- #5, "Short Circuit"
Blade Edge Software
==============================

Another way to do it is to call your own void main(void) function from your WINMAIN where your main game loop will reside then make a function like this

void update( bool updscr )
{
MSG msg;
if (updscr) blitBuffer();
if (PeekMessage( &msg, 0, 0, 0, PM_NOREMOVE ) == TRUE)
{
GetMessage( &msg, 0, 0, 0 );
TranslateMessage( &msg );
DispatchMessage( &msg );
}
}


and all it from within your main game loop. Passing ture as a parameter will update the screen as well as flushing out the message queue while false will only flush the queue

hey Ironside, that''s an interesting approach to this problem... instead of wrapping your Update() function inside the message loop, you wrap the message loop inside your Update() funtion... Hmm.. I must give this a try.

Yeah, Ironside''s idea is pretty nice. However, that means that only one message gets checked per frame. You should use a while() loop or equivalent construct so multiple messages that arrive between frames are handled (like mouse moves.)



Down with Tiberia!

Whoops.. yeah change the if(peekmessage)
to while (peekmessage)

I don''t think it''s wise to have a while() loop in your frame update function solely for the purpose of messages, I imagine that''ll affect your frame rate, and some times, to a significant degree.

Besides... If you''re doing a game, I doubt you''d handle the mouse with WM messages. (The truth is, after a game is initialized, I can''t imagine any useful purpose the Windows messages serve, assuming I''m disallowing alt-tab''ing)

I personally prefer the seperate thread approach, because you can then seperate the OS specific code more clearly, especially if you use APIs like OpenGL, and I honestly can''t imagine that there are any major platforms that most people are developing for which don''t support threads. I''m not saying that I''m right of course...but I like it.

The ''Andre LaMothe Style'' is pretty easy to understand, although I''ve always been reluctant to use it because doesn''t it mean that the frequency of non-rendering functions is limited by the frequency of the rendering function.
eg. if your update function contained:
process_input ()
process_ai ()
draw ()
and draw () took 50ms to complete (thats 20 FPS) then surely process_input () and process_ai () can''t be called more than 20 times a second. That doesn''t make for very responsive input!

or I could be wrong...

..Dr J..