I’m having some badness with a GL app I am working on, basically the app will be a cool real-time effects editor for the next generation of games we are doing at work. I’m not particularly familiar with doing MFC type apps–the standard we use for writing our own in-house tools.
Now to explain the problem…To get the best performance, I decided to make the put the rendering side inside of it’s own thread. The thread gets created when my test dialog gets initialized, then the thread builds it’s own GL window ( it seems to crash if the DC context for the window wasn’t generated inside of the thread that calls the swap buffer…), pasting it as a child on the parent dialog. Then it does a simple color fill…finally, swaps buffers.
So far so good, or so it would seem. I soon discovered that the MFC side of things seems to quickly lose control and doesn’t re-paint after I switch to another app, then switch back. Worse yet, it doesn’t seem to respond to my close requests…so then I have to resort to CTRL-ALT-DEL…then killing that task.
Not cool. Any thoughts? Is this even the most optimal way to architect this kind of application?? Anyway, I’ve included a release build( 20k ) and the source for the test project( 31k ). If anyone has a moment to peek at it, I’d be ever so grateful. ( Just be aware, that you may have to kill the FxEd.exe task if it won’t stop on it’s own )
http://jeffrey_dischler.tripod.com/FxEd.exe
http://jeffrey_dischler.tripod.com/FxEd_src.zip
Thanks much.