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 )
Hey, thanks for offering to take a peek at it…just be aware, that this is mostly just a test to see if this was even a good way to set things up ( hence the code is kind of sloppy…heh heh ).
Anyway, in talking to a guy at work, he made it sound like the OnPaint (WM_PAINT) of the main dialog might be mucking things up…something to the effect of, when an app doesn’t properly handle the Begin/EndPaint…that the app will keep issuing WM_PAINT commands, ignoring any other types of events for that window. If his explanation is correct, that might explain the fact that it never repaints itself and doesn’t respond to any kind of input. I never changed the OnPaint bit of wizard generated code though…
[This message has been edited by Geoff (edited 01-02-2001).]
I have had a look at your code. The OpenGL stuff is fine, and is basically correct (It didn’t always start in DEBUG). If you actually step into your code, you will find that OnPaint is not called. This will mean that the dialog window is never repainted. This probably also means no other messages are getting processed either.
I think (I haven’t tried it, but have had to do something similar before) that it may be because MFC does not know about the window. You should create a class which derives from a CWnd and create the window this way. MFC will then know about the window.
Indeed, it sounds like using MFC is going to be a pain. It’s been recommended that I use straight MFC code to create all threads…windows…etc, otherwise, I can’t be guaranteed that it will work. And even still, there doesn’t seem like much of a guarantee…
Thanks to anyone who checked out the code or offered suggestions.
I haven’t ever had any trouble getting MFC to spawn a Win32 window (supporting OpenGL), and have it process its events.
You do realise that your render thread will also have to have created the window itself, and not just be passed the window handle from outside…?
I’ll have a look at your code at lunch time to see if I can help…
