Resources for Writing Tools in MFC
Author
I am in the process of writing a game engine and application framework. As it stands I am at a stage where I would like/need to create more detailed game resources (maps, objects, scripts, etc.) for testing my engine. I want to write some game developing tools, and to avoid having to write complex GUI routines (and probably even tools for creating my game tool apps) I am looking at using MFC.
I do not have any real experience with MFC other than reading parts of the SDK docs and looking a some sample programs. I am also reading Jeff Prosise''s newest book on MFC. However, I was wondering if anyone knows of some good internet sites relating to writing applications in MFC. I am hopefully looking for a site that is to MFC sort of like what GameDev.net is to game programming (i.e. forums, articles, tutorials, and news).
I could probably write my tools with what I''ve learned from Prosise''s book and the SDK docs, but I would like to be able to see and read about what other people are doing with MFC.
I don''t know of any great websites on MFC. I too am using MFC to build a Level Editor. A great source of help for me has been the Quake 3 level editor Q3Radiant source code which is availible at fileplanet.com.
AAAAAAAAAAHHHHHHHHHHHHHHHHHH!!!!!!!!!!!!!!!!!!
Please, stop and think before you use MFC.
There a many alternatives that you might consider.
Let me explain:
1. MFC is SLOW, for certain tools, this does not mean much,
but if you want to simulate some 3D scene within a MFC
aplication, you might experience a pinch.
2. More importantly, MFC is the opposite of portable. Maybe
you are writing this game by yourself on one machine,
but how about if a friend decides to help. Maybe one buddy
is really good at making maps, or can make really cool AI
scripts, and s/he happens to be running Linux, or Mac, or
Beos, or Amiga...
3. MFC will warp your sense of programming to the extreme.
MFC code is so incredibly ugly, it sometimes boggles my mind.
You couldn''t find this many Macro''s at a C programmers
convention. If you have a strong sense of good programming
style, then maybe this does''nt apply to you...
(beware the dark side)
Alternatives:
Make your own lightweigh, encapsulated window library:
not very easy, but you will find that you are a lot more
comfortable programming with a window library you understand.
A more practical approach. Find one of the MANY window libs
available on the internet. Find one you like. Try it out.
Finally, QT. QT is a gui library wich works on both win32
platforms, and X window systems. I think that they are porting
it to MAC as well. I am not very experienced with QT, but
have heard many good things about it.
Basically, if you want to use MFC, go for it... But FIRST become
aware of the alternatives. Mybe another library will suit your needs better(then again maybe not, but at least you will know!!)
type entity
[
dynamic cmd_interface:
cmd c,
object o=0
[
if:c
call_remote[c,o];
]void;
]
Please, stop and think before you use MFC.
There a many alternatives that you might consider.
Let me explain:
1. MFC is SLOW, for certain tools, this does not mean much,
but if you want to simulate some 3D scene within a MFC
aplication, you might experience a pinch.
2. More importantly, MFC is the opposite of portable. Maybe
you are writing this game by yourself on one machine,
but how about if a friend decides to help. Maybe one buddy
is really good at making maps, or can make really cool AI
scripts, and s/he happens to be running Linux, or Mac, or
Beos, or Amiga...
3. MFC will warp your sense of programming to the extreme.
MFC code is so incredibly ugly, it sometimes boggles my mind.
You couldn''t find this many Macro''s at a C programmers
convention. If you have a strong sense of good programming
style, then maybe this does''nt apply to you...
(beware the dark side)
Alternatives:
Make your own lightweigh, encapsulated window library:
not very easy, but you will find that you are a lot more
comfortable programming with a window library you understand.
A more practical approach. Find one of the MANY window libs
available on the internet. Find one you like. Try it out.
Finally, QT. QT is a gui library wich works on both win32
platforms, and X window systems. I think that they are porting
it to MAC as well. I am not very experienced with QT, but
have heard many good things about it.
Basically, if you want to use MFC, go for it... But FIRST become
aware of the alternatives. Mybe another library will suit your needs better(then again maybe not, but at least you will know!!)
type entity
[
dynamic cmd_interface:
cmd c,
object o=0
[
if:c
call_remote[c,o];
]void;
]
To those who keep insisting that MFC is slow, do you actually have any solid proof of your claims? I''ve been using MFC for quite a while and I don''t have any complains about it, speed wise at least.
I do agree that it isn''t portable, but so is the Win32 API. Heck so is Motif, Cocoa, et al. If you want a framework that''s portable and that looks significantly like MFC, you should try out wxWindows.
==========================================
In a team, you either lead, follow or GET OUT OF THE WAY.
I do agree that it isn''t portable, but so is the Win32 API. Heck so is Motif, Cocoa, et al. If you want a framework that''s portable and that looks significantly like MFC, you should try out wxWindows.
==========================================
In a team, you either lead, follow or GET OUT OF THE WAY.
This is my response archetype:
1. This is only true when there is something wrong with your MFC code.
2. Sure a multiplatform gui library works for simple little programs. But the truth is that if you want your tools to be able to blend in with your OS and work with all the other programs you have (like i do), you have to use a native API. I''m only concerned if the game itself is portable, not the tools.
3. i agree with this one. Anything generated by AppWizard is pure evil. But, if you avoid appwizard, you can write MFC code which is cleaner than Windows API code. and you don''t have to use the macros.
MFC has more support and following that Windows API. I will say no more.
cmaker
- I do not make clones.
1. This is only true when there is something wrong with your MFC code.
2. Sure a multiplatform gui library works for simple little programs. But the truth is that if you want your tools to be able to blend in with your OS and work with all the other programs you have (like i do), you have to use a native API. I''m only concerned if the game itself is portable, not the tools.
3. i agree with this one. Anything generated by AppWizard is pure evil. But, if you avoid appwizard, you can write MFC code which is cleaner than Windows API code. and you don''t have to use the macros.
MFC has more support and following that Windows API. I will say no more.
cmaker
- I do not make clones.
quote:Original post by archetype
1. MFC is SLOW, for certain tools, this does not mean much,
but if you want to simulate some 3D scene within a MFC
aplication, you might experience a pinch.
BULLSHIT! That''s just an old wives tale! MFC is perceived as slow because it uses C++. When you see C++ people assume it''s slow! I''ve used MFC quite often and it''s not slow whatsoever!
NO doubt that if you create you''re own 3D engine using MFC it will be slower then DirectX or OpenGL, but why would you want that? I''ve used OpenGL within MFC apps and the comparision to a plain OpenGL app is unperceivable.
quote:
2. More importantly, MFC is the opposite of portable. Maybe
you are writing this game by yourself on one machine,
but how about if a friend decides to help. Maybe one buddy
is really good at making maps, or can make really cool AI
scripts, and s/he happens to be running Linux, or Mac, or
Beos, or Amiga...
A yes, portability issues! This is always an issue an not just related to MFC, but to any type of development! Chance are your game is already using DirectX, so who cares! Anyways, if you App is well designed and properly modulated you should''nt have to many problems "porting" the app to another platform.
quote:
3. MFC will warp your sense of programming to the extreme.
MFC code is so incredibly ugly, it sometimes boggles my mind.
You couldn''t find this many Macro''s at a C programmers
convention. If you have a strong sense of good programming
style, then maybe this does''nt apply to you...
(beware the dark side)
MFC Code is a little cryptic at first, but so is any other API out there. Just get into it and everything will fall into place, as anything else does. Myself, I learned and got a hang of MFC within a month, it''s not that hard!
quote:
Alternatives:
Make your own lightweigh, encapsulated window library:
not very easy, but you will find that you are a lot more
comfortable programming with a window library you understand.
A more practical approach. Find one of the MANY window libs
available on the internet. Find one you like. Try it out.
This is good, ONLY if you want to do multi-platform programming and you don''t care about performance that much. Some of these toolkits are great and fast, but some are slow... keep in mind they encapsulate the API they are compiled on, better or worse? Your decision!
quote:
Finally, QT. QT is a gui library wich works on both win32
platforms, and X window systems. I think that they are porting
it to MAC as well. I am not very experienced with QT, but
have heard many good things about it.
Ahh... QT! QT is great, but it can be a hassle to create GUIs with it. I''ve used this, and it''s a great tool for multi-platform dev, but be ready to place your Widgets by hand (no GUI editor that I know of...) Oh yeah, it''s not free on Win32, so be ready to dish out some cash...
If this interest you there is also one called FLTK which is free and works similar to QT.
quote:
Basically, if you want to use MFC, go for it... But FIRST become
aware of the alternatives. Mybe another library will suit your needs better(then again maybe not, but at least you will know!!)
Do your research when it comes to this stuff, try different things, but if you don''t care, then use MFC and have fun!
ZaneX
I too must use MFC for my level editor. The reason I must use it is so that the thing will be easy enough for my friends to use it. If I told them it was a command line tool, I''d have to make all the maps myself.
I don''t have to worry about portability since they all use windows. After I write this I will go back to clean code not written by the stupid Wizard.
Actually, does anyone know how to include MFC without using the wizard. This would make my life blissful.
I don''t have to worry about portability since they all use windows. After I write this I will go back to clean code not written by the stupid Wizard.
Actually, does anyone know how to include MFC without using the wizard. This would make my life blissful.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
