MFC
As you have probably guessed already, programming Windows applications isn't the easiest thing in the world. People
tend to fear difficult things, blowing them up in their mind, making them many times worse than they actually are. While
it is ugly code, a lot of the stuff required to make Windows work is used in every application and should be abstracted
away. While there are many libraries on the market to do this, the predominant one is the one made by Microsoft,
called MFC.
MFC, or the Microsoft Foundation Classes, is a system of classes designed to encapsulate the Win32 API. It tries to
create simple ways to do the most common tasks in Windows programs. Your application derives from CWinApp, your
window from CWnd, your dialogs from CDialog, etc. This makes applications much easier to write, as a lot of the
muscle work required in Windows is taken care of for you. MFC is a fantastic tool for making quick front ends to existing
code.
However, things aren't as great as they first appear. First of all, MFC is geared towards document view type
applications (like WordPad). It has loads of code to support docking toolbars, handle modeless dialogs, and work with
the GDI. Unfortunately, those things aren't of much use if all you want to do is make 3D games.
Another inherent MFC problem is the size and speed penalties. The added functionality given by MFC comes at a
price: The DLLs are fairly large, and unless they're already loaded in memory, they can hit your application in load time.
Finally, MFC isn't the perfect bedfellow for DirectX. The programming models with which both APIs are designed are
different. For example, windowed Direct3D applications need to know when the window it is drawing is moved or
resized. However, getting notified of such changes isn't an instant event in MFC, particularly if the DirectX window is a
document window that can move relative to its parent window. These hurdles are not insurmountable; they're just kind
of a pain. Most of your applications will run in full-screen mode anyway and don't need the GUI bells and whistles that
MFC provides.
MFC won't be in any of the code that I show you, so there is no point in going into any more detail about it. However, if
you seriously start developing a 3D game, you'll need utilities to help manage your data. When the day comes that you
need to build those utilities, crack open a good book on MFC and you'll have stuff up and running in no time. One of the
best books on MFC is Professional MFC with Visual C++ by Mike Blaszczak, published by Wrox Press.
As you have probably guessed already, programming Windows applications isn't the easiest thing in the world. People
tend to fear difficult things, blowing them up in their mind, making them many times worse than they actually are. While
it is ugly code, a lot of the stuff required to make Windows work is used in every application and should be abstracted
away. While there are many libraries on the market to do this, the predominant one is the one made by Microsoft,
called MFC.
MFC, or the Microsoft Foundation Classes, is a system of classes designed to encapsulate the Win32 API. It tries to
create simple ways to do the most common tasks in Windows programs. Your application derives from CWinApp, your
window from CWnd, your dialogs from CDialog, etc. This makes applications much easier to write, as a lot of the
muscle work required in Windows is taken care of for you. MFC is a fantastic tool for making quick front ends to existing
code.
However, things aren't as great as they first appear. First of all, MFC is geared towards document view type
applications (like WordPad). It has loads of code to support docking toolbars, handle modeless dialogs, and work with
the GDI. Unfortunately, those things aren't of much use if all you want to do is make 3D games.
Another inherent MFC problem is the size and speed penalties. The added functionality given by MFC comes at a
price: The DLLs are fairly large, and unless they're already loaded in memory, they can hit your application in load time.
Finally, MFC isn't the perfect bedfellow for DirectX. The programming models with which both APIs are designed are
different. For example, windowed Direct3D applications need to know when the window it is drawing is moved or
resized. However, getting notified of such changes isn't an instant event in MFC, particularly if the DirectX window is a
document window that can move relative to its parent window. These hurdles are not insurmountable; they're just kind
of a pain. Most of your applications will run in full-screen mode anyway and don't need the GUI bells and whistles that
MFC provides.
MFC won't be in any of the code that I show you, so there is no point in going into any more detail about it. However, if
you seriously start developing a 3D game, you'll need utilities to help manage your data. When the day comes that you
need to build those utilities, crack open a good book on MFC and you'll have stuff up and running in no time. One of the
best books on MFC is Professional MFC with Visual C++ by Mike Blaszczak, published by Wrox Press.
No comments:
Post a Comment