Does anybody know how to properly use OpenGL in an MFC project?
yeah, drop mfc 
you did say “properly”… you’ll save at least a meg and a half of ram as well 
Originally posted by Moridius:
Does anybody know how to properly use OpenGL in an MFC project?
Depends on what “properly” you meant.
Search this forum by keyword “MFC”, you shall find tons of threads.
[This message has been edited by Coconut (edited 01-15-2003).]
Using it in MFC is similar to using it with plain Win32 programming (WinMain).
Create your context in OnCreate, destroy the context in OnDestroy, render in OnPaint or anywhere else you wish.
That’s the basics.
I went to google.com, typed in “MFC opengl” and this was the first hit: http://www.mfcogl.com/
Have fun!
-SirKnight
Yes, Joel Parris and <a href=“http://www.codeguru.com/” target=“_blank”>
Code Guru</a> both have excellent resources for MFC/OpenGL programming.
FWIW, I prefer to separate all OpenGL handling from Windows/MFC handling to improve portability.
See an example here .
i just prefer splitting all code into os and non-os code; as canned solutions go, mfc is quite a biggy - if you like the ms approach, i’d recommend taking a look at atl, after all ms created it to basically give you mfc as lean as possible.
MFC is not all that big, even statically linked. As the MFC complexity increases size increases also. A 280kB
statically linked MDI OpenGL MFC is trivial on today’s “run-of-the-mill” hardware.
Application Size (kB) Mode DLL?
Win32 (NeHeL5) 44 Release No
Simple MFC 132 Release No
Simple MFC 1,352 Debug No
Dialog MFC 136 Release No
Dialog MFC 104 Debug Yes
SDI MFC 240 Release No
MDI MFC 280 Release No
MFC is a nice solutions if you also need to throw in OS specific code. I read that ATL is not properly supported on VC++ 6, but in .NET probably things have changed.
Are you guys arguing about disk space utilization? Really, who cares. RAM and disk space is plentiful. Even Linux (RH8) is getting gigantic. It needed 1.7 GB when I removed most of the extra software.
Code wise, if you find MFC messy, that’s a different story. I prefer low level stuff compared to languages like VB or something totally object oriented like Java and other crap.
Dont waste your time worrying about size.
fair enough, but i could always use extra 2 (ish) meg of ram (run time data, vtables)… the bloat mfc adds is not that important in itself, but it does reduce “locality-of-reference” (drains both page and cpu caches). as for atl, other than the usual ms “3 million bugs until v3.0 or whenever” stuff, it was supported back on dev studio 5… me, i stick to straight win32, works for me
The reason why I want to learn to include OpenGL into MFC is for application programming along the lines of tools like 3D Studio and such. Of course if I want that level of complexety, I’ll just use the real thing, but MFC is actually a very useful structure for programming tools rather than engines.
Thank you for your quick contributions!
There isn’t anything wrong with making OpneGL programs with MFC. As long as you know what you are doing so you don’t blindly include stuff you’re not using/needing that may slow you down from overhead and stuff. Just look at doom 3. It’s actually an MFC application. If MFC was all that “evil” then you wouldn’t see carmack using it for doom 3. I think if you plan on integrating your 3d editor/s into the 3d engine it is a good thing to make your application an MFC one. Even if your program is a stand alone editor, MFC is a nice way to go. Those things has so much windows stuff in it that it’s just easier to use something like MFC or something similar.
Also you may want to look into C#. It’s easy to use and great for windows apps. It’s pretty fast too. It will provide the ease of making windows apps like VB but at the speed of C++. Of course you will need a C# compiler first. I’ll be getting a copy of VS .NET from my uni soon so I’m going to be looking into C# a bit more. The beta version I had was slow and pissed me off constantly because of that. 
-SirKnight