   GetMessage / PeekMessage
  Most of game programming thread I read recommend people use PeekMessage.  I believe that's because of *mostly* people are writing in a single thread situation.  In a multiple thread game programming situation is it necessary?  The reason I ask because PeekMessage could consume 100% of CPU cycle which isn't good idea in multiple thread situation.I'm thinking to use GetMessage instead since most of the message are user inputs; which is pretty low frequency compare to video and sound processing.  I'm seeking suggestions and coding examples (if anyone would like to share).Thanks   
  Yeah, PeekMessage is usually used instead of GetMessage because it returns immediately if there are no messages waiting. This doesn't mean that you have to use 100% of the CPU though (i.e. simply spinning until messages arrive!). Handling messages is a very small part of a game's main loop, and I wouldn't want to rely on the message pump to be the system that decides when to start/top the game loop.Usually you choose PeekMessage because you do actually want to do something if there are no messages (e.g. run your actual game loop). If there's time left over at the end of a frame, you can yeild the CPU with a Sleep(0) call if you don't want to hit 100% usage all the time.If you're doing a windows-GUI-based game, like Minesweeper etc, then letting the message pump control your game might be the most natural choice, but for real-time games, you probably don't want to use that reactionary paradigm.   ;  Check out this article on MSDN:http://msdn.microsoft.com/en-us/library/ms644928.aspx#examining_queueThe main idea is that you want to use peekmessage in a game so that messages in the queue (i.e. rendering some huge world on the screen) don't have to wait until they finish processing before the user can process other messages, like input.   ;  Thank you for the quick respond guys.I think I need to add or clarify something.  We can simply look at a game as I/O just like other software.  Inputs are keyboard, mouse, and network data (online games).  Outputs are network data (back to server), video, and audio.I think no one would disagree that keyboard and mouse data are very low frequency compare to network data or video rendering.  The problem here is we need to define who is doing what under multi-threaded programming.  Which sounds simply, but if we look at the traditional win32 API programming, the GUI is closely linked with back end programming; and most of all they are sequentially executed.Even the MSDN article (from Megapwnd), also assume we would sequentially execute the window message first, if any.  Due to such coding method, I personally find it difficult to draw a clear line on the coding.  Also, I can't find any resource, example, or tutorials that talking about this issue.So my point is, using GetMessage yield more CPU time, so the video, audio, networking thread would be running most of the time.  However, GetMessage probably won't process as quick as PeekMessage.  Yet, if I use PeekMessage, I better put some coding after that.  Then the question comes how I define the job and coding?By the way, that MSDN article doesn't tell us how to register the window class and the rest of message handling.  I tried to set the lpfnWndProc = NULL which crashed the program.  If I set that to DefWindoProc, the program just won't quit even through I click the close button, it just keeps on running in the background.  Would like to see if anyone could provide a complete coding from beginning to the end of that example.Thanks   ;  The PeekMessage call is tied to your main thread, as are most of your rendering calls. This means that if you pause the main thread until more messages arrive, then you pause the renderer.Also, you shouldn't have an input thread, rendering thread, audio thread, networking thread, etc... It's much better to simply have a pool of threads (as many as are suitable for the CPU being used) and then schedule jobs to be executed on each other those threads yourself.e.g. the workload on a thread-pool with 3 threads might look like:Thread 0 | Input | Scene graph | Physics    | Rendering | Audio | Networking  |Thread 1 | Scene graph  | Physics   | Audio | Networking    | sleep |Thread 2 | Scene graph | Physics    | Audio    | Networking    | sleep   |    |   |    ^ start of frameend of frame ^;  Thank you for example again, but that rise more question.I'm afraid the way how those thread operation would create more synchronization problem since all 3 of them are accessing same data fields.  Also, why have thread taking care of same task wouldn't be a good idea?Anyway, is there any books or online resource talks about issue topics?  Or we shall just keep this thread going?Thanks.   ;  Before changing the topic too much - PeekMessage + calling Sleep from within your game loop still stops your game from using 100% CPU time, plus it keeps your game more responsive than it would be using GetMessage.Quote:Original post by dm_3xI'm afraid the way how those thread operation would create more synchronization problem since all 3 of them are accessing same data fields. Also, why have thread taking care of same task wouldn't be a good idea?If you don't want to split tasks across threads like in my first example, you can still use a thread pool to manage all of your jobs without making a thread of each job.e.g. Input and Rendering might be fixed on Thread 0 (Windows Message API and DX9/OpenGL require these to be on the main thread), but all of your other jobs can be put into a queue, and then any thread in your thread pool can take jobs from the queue it goes. Maybe one frame the physics will be done by thread 2, but on another frame it will be done by thread 1.Thread 0 | Input | Rendering    | Audio |Thread 1 | Scene graph  | Networking | wait  |Thread 2 | Physics   | wait   |    ||    ^ start of frame  end of frame ^Creating too many threads harms performance (when the CPU switching from one thread to another you incur a performance hit). With a thread pool you've just got "worker" threads that you can feed jobs to. On different CPUs you can create different amounts of threads (depending on how many cores they have).These different jobs can have dependencies on each other (the "Multicore Programming" paper below shows how you can use pipelining to remove dependencies through buffering though!). For example, the "rendering" job may require the "scene graph" job to be completed before it can begin, in this case the thread usage might look like this (thread 0 stalls before starting on rendering):Thread 0 | Input | wait | Rendering    | ...  |Thread 1 | Scene graph  | ...  |Or a different job could be processed on thread 0 before the rendering job:Thread 0 | Input | Audio | Rendering    | ... |Thread 1 | Scene graph  | ...  |You should try to arrange your schedule/job-queue so that dependent tasks are placed as far apart as possible (like in the second example, where Audio is inserted) to reduce the possibility of stalling the threads.Back to my original example where every thread processes every job -- in this model, the jobs are actually "job groups".For example, the "Scene graph" job might actually be made up of 1000 "update transform jobs" - in this case, each thread can be given 300-400 of these smaller jobs each. The jobs are written in a self-contained manner so they don't need any external information (and therefore don't need expensive synchronisation). After all of the sub-jobs in the "Scene graph" job-group are completed, then the Rendering job-group will be allowed to execute and use the data that was produced.The idea behind this is described on one of the "effective concurrency" articles below (and Tim F's 4th link) - you want your program to scale to any amount of cores, not just a fixed number.If you make 3 jobs on 3 threads, then your program only scales up to 3 cores. If you break those 3 jobs into 3000 sub-jobs, then execute them on a thread-pool, then you program will work on 3 cores, or 32 cores!Quote:Anyway, is there any books or online resource talks about issue topics? Or we shall just keep this thread going?Here's some links from my bookmarks... they're a bit all over the place sorry :/Multicore Programming Two Years Later (lots of good info from 2 years after the 360 came out - ideas like double-buffering data to reduce synchronisation requirements).Insomniac R&D has some interesting ideas.Capcom's engineThe Pillars of Concurrency (and the rest of the articles in the "effective concurrency" series)About 3/4 into this PDF there's some info on PS3 multi-threaded renderingMore stuff on PS3 multi-threaded ideasSmoke - Game Technology DemoDesigning the Framework of a Parallel Game EngineMike Acton's sketches (pretty low-level details)Posts from Tim Farrar: 1, 2, 3, 4Do-it-yourself Game Task SchedulingParallel Futures of a Game EngineThe Future of GPU Computing[Edited by - Hodgman on April 19, 2010 4:29:11 AM];  If you have a bad operative system like windows you might need a thread pool. Otherwise you can have dedicated threads because the operative system will do the scheduling for you. This way it is easier to balance the load to. Threads that do slow things can have much more sleeping inside them.I am using SDL_PumpEvents in the render thread since due to GLX issues it need to be there.But the only events that need to be handled there are focus and window resize.All other events are handled by SDL_PeepEvents in a IO thread that gets 10 events at a time process them and then sleep for typical IO input frequency divided by 2 to be sure not to miss anything (Think I sleep for 12 ms). Also if any event processing gets heavy the sleeping need to be dispersed inside that code to get no hogging of the other threads...(total sleep time in the thread should remain constant)   ;  Sorry to thread jack but it seems on topic. I have PeekMessage in my game update function as follows:bool Game::update(long newTime){prevTime = gameTime;gameTime += newTime;MSGmsg;//pump the message loop    while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))    {TranslateMessage(&msg);   DispatchMessage(&msg);    }input->read();// makes all objects thinkreturn think();};Its not clear to me from the MSDN documentation if this could ever cause the game to get stuck here if messages are generated during the translate/dispatch. More generally, does this seem like a sane way to handle pumping the message queue? I haven't added a menuing system yet but realize that the game will not update during that but still need the message queue pumped so I either need to still call this function or also pump the queue from the menu system.I'm working on my first engine so I know I'm going to learn by making lots of mistakes but would be glad to hear how other coders work the pump into their engine.   ;  I can't answer your questions directly, KevArnold.But I'm doing something similar that create a thread that runs the window itself.  The observation was pretty interesting.  The non-working code was I created a thread that ONLY handles and window message update, something like this:unsigned long __stdcall Threadfunction ( void ){   MSG msg ;   int errb ;   while (( errb = GetMessage ( &msg, NULL, 0, 0 )) != 0 )   { if ( errb == -1 ) {    MessageBoxA ( NULL, "Get Message Error", "Error", MB_OK ); } else {    TranslateMessage (&msg);    DispatchMessage (&msg); }   }}int init_window ( ..... ){   // call RegisterClass, CreateWindow function here...etc   // This thread handle the window message loop   thread_handle = CreateThread ( ... );}// other functions below including the call back.doing the way above, the window doesn't work at all.  To get my window to work.  All procedures from RegisterClass, CreateWindow functions have to be INSIDE the thread function.  Which seem pretty interesting to me.  However, that does NOT happen if I don't use thread.  The message handle function could be a stand alone function.Hope that help   