by adde » Jul 3, 2003 @ 3:58am
Obviously you can, since not many regular GUI applications are multi threaded.
But the problem is that you want to call GameLoop() over and over. If you create two windows, you have two game loops to call. Without building some sort of global queue of window objects, calling each after another, the simplest way is to use a separate thread for each window.
As you said, the message pump (or whatever it's called) will take care of all the window messages and dispatch them to their respective window. BUT this is provided that the main thread (or GUI thread as I would like to call it) doesn't get stuck somewhere.
For instance, say you get an event from a menu or a button and you want to create a new object/window or call a function in a given object as a result. If that object (or function) has an infinite while loop (or for some other reason doesn't return to the event handler function) it will lock the GUI thread and you'll stop processing events.
So, this is why you need one thread for each window, to keep the GUI thread free.
Had the window been a standard ATL window which is only updated/redrawn when it recieves a WM_PAINT event, then you only need a single thread because it will never get stuck (unless you call an function that doesn't return to the event handler ofcourse)
Come to think of it, you should be able to rewrite PF using the WM_TIMER event to call GameLoop with a given interval, and then use Suspend() and Resume() to stop and start the timer. This will work with a single thread. Provided you only update the window that currently has the focus, this approach will behave exactly as the multiple threaded one if you set the timer correctly. If you want several windows to update its content simultaniously, then perhaps the WM_TIMER approach will work even better since each window will wait for the other to return from the WM_TIMER event handler function. The only way to get this with threads is to define them as uninteruptable (you can do this in WinCE but not on Win32) and hence you should avoid updating more than one window at a time (it will produce flicker or not fully updated windows)
Hmm.. seems the WM_TIMER approach would be better. I don't know why I didn't use it myself. Probably because I didn't knew it excisted and I knew I would use threads for some network stuff anyways. I guess the only hard part is to figure out a good timer interval. On WinCE the timer resolution is 1 ms/tick, but on 2000/XP it is 10 ms and on ME/98 it is 55 ms giving a maximum (theoretical) framerate of approx 18 which is way too low. Setting the interval to 1 (tick) will guarantee the fastest performance, and the windows will interleave in random order (but never twice in a row).
Anyways.. that's something to think about.