I posted this once but it didn’t seem to make it. So please forgive if it appears twice.
I’ve been working on a new framework that I can use for the various GL applications that I may develop in the future. I’ve pieced to gether code from NeHe, Super Bible, my own code etc. I currently have a Win32 based framework (WinMain, WndProc etc.) which support full screen, windows as well as being multi-threaded. There is a the main thread which handles events, window creation etc. and a rendering thread which sets up the GL context, intialized GL and renders.
My question is this. Do any of you have thoughts on which makes the best framework for developing graphics apps. Are there any trade offs for speed ? Will the multi-thread aspect work well in the MFC context? Basically I want to spend some time, get a nice basis/framework to work from and then ignore it as work on the “fun stuff” I’ve done both types of programming so that is not an issue.
I’ll probably be playing around with writing screen savers, some basic data visualization, playing around with new techniques and possible some terrain modeling with LOD or ROAM.
You sholdn’t use MFC. IF you can make your window only with the OpenGl’s functions it will be well. From what I know if you use MFC you should provide mscvrt.dll to make them run. The same thing in valable for Nehe’s tutorial (he doesn’t explain this!)
You can’t open your own windows by using only OpenGL. OpenGL is only an API for rendering on an existing window (to be more exact: on an existing DC). This has to be created by something else. This can be MFC or e.g. glut. With glut it is very easy to control the windows, mouse- and keyboard-events. On the other hand everybody who wants to run your prog needs the glut32.dll. The same problem as with MFC, there he needs the msvcrt.dll. But this can be solved by link the exe statically. This gives the exe a bigger size, but it will run everywhere. Another pro for GLUT: It also runs on UNIX-systems. MFC won’t run on UNIX (except you buy a tool which can this).
Now it’s your decision
[This message has been edited by Kilam Malik (edited 07-21-2000).]
As far as MFC is concerned, you can easily distribute it with your program. If you are using InstallShield xxx, you can tell it to include MFC 4.2 in the installation… This not really difficult…
Moreover, some MS programs use MFC and install it automatically (and MFC should come with any Windows as well !).
You say you have the framework etc done
in Win32, thats good, and now you want
to use MFC to take advantage of the MFC
function when doing utility stuff?
(Thats the only reason for me anyway,
MFC = Faster Utility creation).
When beginning from scratch with MFC and
openGL there are some things which you want
to do different, depending on the type
of MFC Application ( Dialog, document.etc. )
you want. But it should not be too difficult.
They have a very good selection of MFC
code ( including OGL ).
Personally I would not use MFC since I
want my code to run on BeOS/Linux etc, which
is very easy with c++ and OGL.
Regarding the speed penalty, not much.
I have seen many threads on this and they
have almost all said that with todays machines you dont loose hardly anything.
“Will the multi-thread aspect work well in the mfc context?”
I am not sure I got that =).
If you know MFC and can take advantage of
it and want your code only on Win, go for
it. If not, use Win32.
Thats my 5 cents ( and thats not much .
Marcus “Cruxis” Lenngren - Nopp
[This message has been edited by Cruxis (edited 07-21-2000).]
I haven’t been able to logon onto the newsgroup for awhile so it was nice to see I had gotten replies, kind of like having a message on your answering machine when you get back from a trip.
The replies gave me more to think about.
I will elaborate on a couple of points.
I asked about multi-threading vs win32 and mfc. I have my framework setup now (using win32) as a multi-threaded app. That is, I have a thread for rendering and a thread for the main win32 app(process events etc). My question was more if anyone knew of problems using MFC multi-threading for GL apps? I now it gets kind of tricky, with creating windows, contexts etc. updating information, adding critical sections …
I have no real need for MFC right now, I guess I feel strange for not using it as that has been what I used on the job for all the apps we have developed.
I guess the thing to think about is do I want to create UI elements etc. easily if so I should use MFC.
One other thing, I have found that MFC doesn’t really fit a lot of graphics apps. MFC relies heavily on the View/Doc architecture which doesn’t always fit that well for game/graphical applications.
One other point that was brought up was “don’t use MFC if I want to port the app”. Not sure I understand this. If I use win32 I’m still tying myself to windows. I am trying to isolate the windows specific stuff, window creation, event processing etc. so it shouldn’t be too difficult to move to another platform.
Thanks again for the replies and let me know if you have other thoughts/suggestions.
.