🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
MFC vs. win32
Author
OK, I know everybody has probably seen this question before--except me. The question: is MFC too much larger/slower than win32? That''s sort of ambiguous, so I''ll try to clear things up a bit:
I like MFC because of the structure--I''m a real structure freak. I love all the different inheritances and how a pointer to CObject could be very powerful. However, win32 is attractive because it''s more ''native''--more natural to Windows. It''s also big and hairy. So, is it worth the smaller space/extra speed to use win32 instead of MFC?
Thanks...
MFC is very useful for many things such as writing word processors and other document oriented structures... However, IMHO it is an inflexible structure that does not lend itself to writing a game. Of course, it DOES lend itself to helping in the process of writing editors necessary for a game because of this structure.
I guess my opinion is that it has its uses... but writing the actual game is probably not one of them.
I guess my opinion is that it has its uses... but writing the actual game is probably not one of them.
I''m probably going to get yelled at for this... but I disagree *smile*
I have a little game called Peg on my site (www.knightsvalorous.com) that was written in MFC using a custom control and pure GDI. It took me about 8 hours to code, then I spent some time struggling with Truespace trying to make spiffy sprites to replace the plain ones I originally used. I wrote it because I was so terribly frustrated with DDraw (which I later found out was actually a problem with my video card, which had a really messed up memory sector that apparently got worse daily until my screen suddenly locked into 640x480 mode one day, now that I''ve replaced it everything is peachy.)
More and more I''m thinking it''s really a matter of preference. I''m messing with a sidescroller now that has a relatively thin MFC base underneath DDraw. I''m a real structure/OOP freak too, and I feel more comfortable with that underneath me (not to mention the fact that I write custom controls and MFC ui''s for a living, which might have something to do with it...) There are several DDraw-on-MFC-base games with the source at www.codeguru.com in the Samples section you might want to look at if you want to use MFC and DDraw together, and I also have a really good book called DirectX Complete which approaches it from an MFC base.
Use what you want. As long as your finished project rocks, who cares what it was built with? *smile*
-fel
I have a little game called Peg on my site (www.knightsvalorous.com) that was written in MFC using a custom control and pure GDI. It took me about 8 hours to code, then I spent some time struggling with Truespace trying to make spiffy sprites to replace the plain ones I originally used. I wrote it because I was so terribly frustrated with DDraw (which I later found out was actually a problem with my video card, which had a really messed up memory sector that apparently got worse daily until my screen suddenly locked into 640x480 mode one day, now that I''ve replaced it everything is peachy.)
More and more I''m thinking it''s really a matter of preference. I''m messing with a sidescroller now that has a relatively thin MFC base underneath DDraw. I''m a real structure/OOP freak too, and I feel more comfortable with that underneath me (not to mention the fact that I write custom controls and MFC ui''s for a living, which might have something to do with it...) There are several DDraw-on-MFC-base games with the source at www.codeguru.com in the Samples section you might want to look at if you want to use MFC and DDraw together, and I also have a really good book called DirectX Complete which approaches it from an MFC base.
Use what you want. As long as your finished project rocks, who cares what it was built with? *smile*
-fel
quote: Original post by Anonymous Poster
They won''t just yell at you fel, my thoughts verbatim.
Why does this lose my name every other day???
Hmm,
The Anonymous Poster
As long as you don''t do anything stupid like trying to put your game data in a CDocument and the output in a CView, then MFC is really a thin layer. And some of it''s utility classes are pretty spiffy too.
IMO, though, if you''re going to use a windows framework, OWL is the way to go. OWL gives you the object framework under you, and it''s organization in a manner that makes sense for a program that is more application centric. (i.e. games)
And if no one else out there has heard of OWL, I think I''m going to cry.
IMO, though, if you''re going to use a windows framework, OWL is the way to go. OWL gives you the object framework under you, and it''s organization in a manner that makes sense for a program that is more application centric. (i.e. games)
And if no one else out there has heard of OWL, I think I''m going to cry.
MFC is not the only class library out there for windows app frameworks.
The Borland''s now defunct OWL was I think the first one for Windows.
I prefer using Borland C++ Builder, for a couple of reasons.
One is the VCL, which comes from Delphi, and although that library is Object Pascal, I don''t care because I just want to throw together a generic UI and nothing I''ve seen is faster and easier than C++ Builder. I just want to have a decent looking UI quickly without having to do a lot of work. If you''ve never seen
Another is Borland has one of the best, ie closest to the standard, C++ implementations available. They even have links to the info on the results of their standard conformance tests.
I can''t tell you how many times I''ve tried things in MS VC++ only to discover it didn''t work properly and the compiler did not catch it with any kind of error.
As for the using MFC for a game app framework, why not? As long as it works, people who play your game don''t care how you made it.
The Borland''s now defunct OWL was I think the first one for Windows.
I prefer using Borland C++ Builder, for a couple of reasons.
One is the VCL, which comes from Delphi, and although that library is Object Pascal, I don''t care because I just want to throw together a generic UI and nothing I''ve seen is faster and easier than C++ Builder. I just want to have a decent looking UI quickly without having to do a lot of work. If you''ve never seen
Another is Borland has one of the best, ie closest to the standard, C++ implementations available. They even have links to the info on the results of their standard conformance tests.
I can''t tell you how many times I''ve tried things in MS VC++ only to discover it didn''t work properly and the compiler did not catch it with any kind of error.
As for the using MFC for a game app framework, why not? As long as it works, people who play your game don''t care how you made it.
I''ve never used MFC and I have very little knowledge of it. Win32 works fine for me, cause I don''t want to learn anything that isn''t really that important in the games I''m writing.
I''ve put my time on learning directdraw and now d3d im, cause I feal that is more important than mfc.
I''ve put my time on learning directdraw and now d3d im, cause I feal that is more important than mfc.
I''ve written a number of programs in both MFC and OWL (not at the same time, of course), although I''ve tended to stick to "pure" Win32 for actual games (as opposed to editors). Both class libraries have their upside, although with OWL one is always left with the feeling that Borland took what they thought Win32 should be and tried to code it - hence, sometimes you find yourself having a bit of a battle with the OWL mindset just to do something relatively simple that a lot of Windows programs do..... likewise, with MFC it can be a little hard to escape its mindset when you want to do something different. MFC, at least in its earlier editions (and still if you ignore CDocument, CView and some of the other utilities), had the advantage of being very thinly spread over Win32. OWL isn''t very thick either, but the extra abstraction (away from Win32 towards Borland''s idea of how things are meant to work) can be a little costly.
Of late, I''ve found that I write more and more business apps, utilities and game editors (I''m a computer consultant who does custom programming by day) in Visual Basic for ease/speed of development and just throw in MFC/ActiveX custom controls as needed. Even my editors tend to be a VB program using my graphics code in a DLL.
MFC isn''t great for games, but it certainly makes earning a living writing software easier!
Of late, I''ve found that I write more and more business apps, utilities and game editors (I''m a computer consultant who does custom programming by day) in Visual Basic for ease/speed of development and just throw in MFC/ActiveX custom controls as needed. Even my editors tend to be a VB program using my graphics code in a DLL.
MFC isn''t great for games, but it certainly makes earning a living writing software easier!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement