I''ve decided to go after MFC, but I still need a little help. First, are there any good tutorials on making only the most basic windows under MFC? Every book I have tells me how to use AppWizard, but that code always seems to have too much extra weight. Basically, I just need...well...the basics. Message Handler, Game Loop, that stuff. Second question: has anybody used (or even looked at using) the CList and CArray classes? Are they too slow or something? I''m still trying my hardest to switch to VC++ (from VB) and I''m not much of a pointer person...these classes seem to be the answer to my problems. Any advice here? Thanks aforetime! 2mikes.com
FEE

Well try the micrsoft msad web site

http://msdn.miscrosoft.com

MFC was made by mircosoft...they have good information''s about-it!

First, get "Programming Windows with MFC" by Jeff Prosise. This book is great. No AppWizard or ClassWizard or anythinhg else like that. It teaches MFC from the ground up from purely a coding perspective. Hell, you could write MFC apps in Notepad after you read this book. (Although that would just be sadistic).

Ummm, you really do need to learn about pointers. I know they are difficult to grasp, but they are such a cornerstone in C/C++ that there''s no real way to sidestep them. Trust me, once you figure them out and why they are used, you''ll understand how powerful they really are.

As far as CList and CArray, I''m not certain. I used CArray once in an office application I wrote, but speed wasn''t critical there. I believe they work by dynamically allocated memory whenever you exceed the array''s size. I don''t know if only new memory is allocated only for the new entries needed or if an entire new array is allocated and everything is copied over. Either way, I wouldn''t expect it to be very fast.

If you are just dead set on using them though, make sure that you find a good initial size and grow value for your problem. The grow size is how many more nodes are added once the array has to increase in size. If it''s too small, you''ll be allocating memory all over the place, and if it''s too large, you''ll just be wasting memory.

For a problem like that, linked list are probably better, but then there comes the pointers, etc...

MFC is pretty nice to throw together an application or tool, but I would stay away from it for games. There is a LOT of overhead inherent in the class structure.

That being said, CList and CArray are very handy, but somewhat slow. there is a LOT of dynamic memory allocation and General-Case overhead that could be avoided easily by writing your own tailored list or array class.

If you''re putting together an application using MFC, there really isn''t much better an approach than to use the Appwizard, IMO.. saves you a LOT of time. However, if you wish to learn whats going on, I would suggest studying the code that appwizard puts together, and learn whats going on with the help files provided with MVC++. Note that ALL MFC code has this extra weight, as far as I''ve seen. With careful study you can find what bits of appwizard can be stripped out, such as: Menu handling, toolbars, status bars, and Doc-View (HUGE waste in a game).

I use MFC for level editors and such, while writing the game itself in lower-level C+ (meld of c and c++ code).


*oof*

I loathe the MFC container classes (CArray, CTypedPtrArray, etc). The array classes use a hash table, which is completely inappropriate for some arrays, and whose table depths have to be manually initialized. Never mind the fact that you have to overload all these "helper functions" to get any custom class to work. Perhaps my biggest beef is that it uses the hideously inefficient quadratic key with any class that can be converted to a string, i.e.:
key for "key" is ''k'' * 64 + ''e'' * 32 + ''y''. Fine for small strings, but I was trying to make an array of large strings. Talk about painfully slow access.

Anyway, I would normally say "learn STL". Well, I''ll say it anyway. Learn STL. But if you''re not comfortable with pointers, it tells me that you''re a beginner, and STL is pretty advanced (although amazingly useful). It might be a good thing for you to start with implementing an array or list class yourself, get you into the groove of things.

As for MFC, I highly recommend the "Scribble" tutorial. Even though most people around here seem to berate the document-view architecture, it does have its place. You can probably ignore that part of it and just get an idea of how the view works.

To get the "raw app" you want, take these steps:
1) Use appWizard to create a new MFC application (say "Game").
2) Select "Single Document". If you have 6.0, I think it allows you to un-check document/view architecture. Go ahead & uncheck it.
3) Click "Finish". This will automatically give you a toolbar, status bar, some other stuff. It''s easy to remove later.

If you weren''t able to uncheck the Doc/View tab, here''s what you want to do:
1) Remove the files "GameDoc.cpp" and "GameDoc.h" from the project. This can be done via the FileView tab in your "Workspace" toolbar (menu View->Workspace).
2) Go to the function GameApp::InitInstance. Delete all the malarky about document templates and command line parsing. It should basically look like this:

// ...snipped top of function...
// Change the registry key under which our settings are stored.
// TODO: You should modify this string to be something appropriate
// such as the name of your company or organization.
SetRegistryKey(_T("Local AppWizard-Generated Applications"));

// To create the main window, this code creates a new frame window
// object and then sets it as the application''s main window object.

CMainFrame* pFrame = new CMainFrame;
m_pMainWnd = pFrame;

// create and load the frame with its resources
pFrame->LoadFrame(IDR_MAINFRAME,
WS_OVERLAPPEDWINDOW / FWS_ADDTOTITLE, NULL,
NULL);

// The one and only window has been initialized, so show and update it.
pFrame->ShowWindow(SW_SHOW);
pFrame->UpdateWindow();

return TRUE;
}

3) Go to the "CGameView" class, and remove all instances of GetDocument and CGameDoc.
4) Compile the sucker & remove any other instances of the doucment there may be left in there. (haven''t done this too much, so I might have forgotten something.

Now you have a program with very simple structure:
- CGameApp class is created when you execute the program. The first thing it does is call InitInstance, which creates the frame.
- CMainFrame class is created by CGameApp::InitInstance. This class represents the frame around your game''s window. This includes the window title, the size & position on the screen, moving & resizing, the menu (file, edit, etc.), the toolbar, and the status bar at the bottom. Basically, everything that''s in that window except the white space in the middle is the frame.
- CGameView is the white space in the middle. This is where your game''s display and mouse inputs will take place.

Hope that helps you get started.

MFC is GREAT... for Windows applications. I did some office application programming for a couple years and MFC worked very well. MFC is very well suited for things like level editor and other custom tools. Basically, any standard Window''ish program. Although the Doc-View architechure is a little mystifying at first, it can save you weeks of work.

As far as games go, Win32 API is the only real way to go. In games, you want speed and control. MFC trades speed and control for functionality and ease. This really isn''t that bad though since most games only use a minimal amount of Windows code anyway.

Thanks for the extra info Stoffel. I didn''t know that.

It may look like a pointer, work like a pointer, but hey, it''s a god damn Iterator-What-The-Hell-Is-That-How-Did-They-Do-That-Works-Like-A-Pointer-Thing???

just wanted to say that

"That"

ooh while we''re on the case of STL, may I recommend the book from Addison Welsey "Generic Programming and the STL"
It explains rather well the workings of STL.

MFC collection classes and STL? Is that really a choice?

Com''on everybody, stop using MFC (Microsoft Fustration Class) and head to http://www.relisoft.com/ and learn pure Windows programming. See what they can tell you. Soon you will know. I used to using OWL and then MFC; now say no more to them.

MFC may look easy to start, but you will find it more difficult if you try to learn what ''behind the scene''. Doing anything beyond what MFC can do for you by default really give you a headache. BTW, MFC is buggy too, since it is a one-big-gigantic class library framework.

Just a comment/suggestion.

http://www.codeguru.com is an excellent source for MFC information, if you choose to get into MFC. MFC does look very good on your resume, but unless you're making really simple board games, I wouldn't use it for games. It is a very nice thing for business applications, and much more powerful than VB (though writing apps in MFC is just as fast as VB once you're used to it)
As for MFC and STL, I use the two together constantly. Granted you can't pull off level 4 debugging if you do that, but from what I've seen professionally, it's worth it to use STL instead of the standard MFC container classes.

-fel

Edited by - felisandria on 1/27/00 11:33:41 AM

http://www.codeguru.com is great, but I am not sure it would be real good for learning. It seems targeted to programmers who know MFC and are looking to learn some more advaced techniques. (There''s more than MFC here now and everyone should at least check it out).

For getting into professional game programming, MFC is something good to know. You won''t use it in games, but it''s very handy for tools programming. Depending on what a company''s needs are, this can be a good way to break in.