   Avoiding the Win32 message loop
  Ok I wanted to get some feedback on various methods people use to avoid stalls caused by the Win32 message loop. For example, when you drag the window, click a menu, pretty much any window-related task, your game freezes for the duration. This is not only annoying, but could wreak havok on networking and timing code.The solution I currently use is to run the game engine in a separate thread, leaving the main thread free to wait in the messasge loop. This works perfectly, except for the fact that DirectX doesn''t like to be run in a thread different from the message loop, and certain important Direct3D functions refuse to work otherwise. It required a few hacks to get around this (using message callbacks to have the main thread execute the particular function for the engine). But this feels too messy, especially if I ever decide to split the graphics code off into a DLL or library. I don''t want special-case hacks to litter my engine.So, I''m looking for alternatives. What method do you use to avoid the message loop? Any ideas? 
Qt helps you avoid the Win32 message pump.Essentially it just hides it under a layer of abstraction. You don''t have to deal with it, though (except in very specific circumstances). ;isn''t there a free version of QT, too ??? DJSnow---this post is manually created and therefore legally valid without a signature;quote:Original post by Nairou  Ok I wanted to get some feedback on various methods people use to avoid stalls caused by the Win32 message loop. For example, when you drag the window, click a menu, pretty much any window-related task, your game freezes for the duration. This is not only annoying, but could wreak havok on networking and timing code.Actually your game doesn''t freeze in those circumstances. The window just doesn''t get updated, so your grapics appear to freeze. Your code is still being executed. ;  Well, yeah the code doesn''t exactly freeze, it just gets stuck within the message loop, handling a constant stream of messages. I''ve got the game code written after the message loop, so it get executed if there are no messages to be handled. This is the common design you see in tutorials and here on GameDev.Net. So the code execution never gets past the message loop, and never runs the game code. I doubt window updates have anything to do with it since its a full-window Direct3D screen, which doesn''t use the windows Paint functions. And if the game code WAS still being executed, I don''t think things like framerate counters would get thrown off by the freeze. ;  Well im just a newbie but if understand it right the deal with the fps cunting getting all wierd when you grab a window is because it wont render during that time, resulting in that the mainloop is run very fast ( not having to wait for the slow render functions). thats why you get high values on the fps counter.Atleast thats what i figured ;  Maybe I have misunderstood it then. It just doesn''t make sense that way, and all of my rendering runs just fine when its in a separate thread (naturally), even when the message loop is tied up.Maybe I''m just doing it wrong? Does everyone here just use a single thread for their engines, and not experience this rendering freeze effect? Perhaps the structure of my message loop is inefficient. Can someone provide an example of how you do it?Essentially what I''m saying is, the only way I found to prevent the graphics rendering from freezing everytime you drag a window or hit Alt, was to put it in a separate thread, separate from the message loop. I''d really like to know if theres a better way to do it (without using external libraries like Qt), while still only using one thread, but without the interference problems from the message loop. If anyone has examples or ideas, I''d really appreciate it.;  The typical message/game loop looks like:while (true){    if (PeekMessage(.....))    {   Translate   Dispatch    }    else    {   Do a frame    }}  Get rid of the else and always do a frame. That tends to help smooth things out. It''s still possible to see some glitches if handling a particular message takes a long time, but it shouldn''t happen often.;  I render in a seperate thread,I use opengl though and it works fine ;  Dave Hunt: Huh okay, I guess I''ll try that then.One thing I did notice... I decided to look at some existing games, like UT2003, which allow you to run it in a window. I found that it freezes up in the same way when you grab the window or hit alt. Graphics halts, sound stops, etc. The entire game seems to freeze, since when I release it, it resumes from where it froze, rather than jumping ahead.So I guess this typical single-thread method is what everyone is using? I''m just trying to make it as robust as possible... 