Archived

This topic is now archived and is closed to further replies.

Promit

Is MFC all or nothing?

Recommended Posts

I want to use certain MFC classes, but a lot of MFC really sux for a game. Can I do this, or will I need to come up with another solution? People are saying that only MFC apps can use MFC utility classes...i was hoping thats not true.

Share this post


Link to post
Share on other sites
MFC generally requires you to include the afxwin.h header, but afxwin.h doesn''t get along too well with the usual Win32 headers. You can generally use any MFC classes you want, but be sure to call AfxWinInit() and use the /GX and /MT compilation flags.

What parts of MFC are you specifically interested in?

I wanna work for Microsoft!
[ GDNet Start Here | GDNet Search Tool | GDNet FAQ | MS RTFM [MSDN] | SGI STL Docs | Google! ]
Thanks to Kylotan for the idea!

Share this post


Link to post
Share on other sites
MS claims CString can be used by including only afx.h and not making your project an MFC project. They lie. As soon as you include "afx.h", you get undefined symbols (some of the thread functions). If you can figure out how to do it, please let me know. I''m not ashamed to say that I think CString is actually better than std::string (because at my heart I''m still a sprintf guy, and that''s what CString::Format does).

As far as CFile goes, that involves an entire hierarchy, I believe, so you may have a hard time getting that in with the rest of MFC.

If those are the only classes you want, and you don''t want MFC, you could use std::fstream and std::string instead. They may not be as familiar to you, but they''ll get the job done.

Share this post


Link to post
Share on other sites
quote:
Original post by Stoffel
I''m not ashamed to say that I think CString is actually better than std::string


The two classes are the results of very different thinking in design terms. CString was designed in a world devoid of template techniques, which means it lacks the genericity and extensibility of the std::string class.

Basically, it looks to me like MS just dumped all the functionality they could into the CString class, giving a rather fat public interface. std::string, on the other hand, takes an entirely different approach - one of integration with the STL.

Since a lot of the functionality contained within CString is parelleled in the STL through algorithms and other classes, std::string is able to deal with a smaller set of responsibilities. I know which design I prefer.

--
The Dilbert Principle: People are idiots.

Share this post


Link to post
Share on other sites
quote:

...but a lot of MFC really sux for a game.



Like what? A lot of people like bashing MFC as being "bloated" and "slow", but I haven''t found that to be the case. There is a lot to MFC that you probably shouldn''t use in a game, so don''t use that.

Take care,
Bill

Share this post


Link to post
Share on other sites
Its not that MFC is slow or bloated. But I feel that Event based programming just doesnt "work" well with games. Thats why I dont particularly like GLUT either.

Share this post


Link to post
Share on other sites
quote:

Its not that MFC is slow or bloated. But I feel that Event based programming just doesnt "work" well with games. Thats why I dont particularly like GLUT either.



I agree with you. I have an MFC/DirectX based trial app that I''m putting together. It has a CWnd that manages the D3D variables, but I''m using DirectInput instead of the standard windows events. If it works, I''ll get the best of both worlds.

Take care,
Bill

Share this post


Link to post
Share on other sites
I''d nudge you towards std::string, std::stringstream, and either std::fstream or the Win32 functions Open/Read/WriteFile(Ex).

...
If you use a seperate thread to render the graphics, the advantages of event based program become evident again - and the primary disadvantages of MFC disappear (rendering in OnIdle or OnTimer suxors).

Share this post


Link to post
Share on other sites
[ sarchasm ]
Yes, event-driven architectures for games totally suck. I absolutely love it when I tab-out of Diablo 2 while I''m in town (doing absolutely nothing) to check a web page for an item set and my CPU is pegged at 100%. Doing. Absolutely. Nothing.
[ /sarchasm ]

Share this post


Link to post
Share on other sites
quote:

[ sarchasm ]
Yes, event-driven architectures for games totally suck. I absolutely love it when I tab-out of Diablo 2 while I''m in town (doing absolutely nothing) to check a web page for an item set and my CPU is pegged at 100%. Doing. Absolutely. Nothing.
[ /sarchasm ]



Well, that''s a good point. What''s worse is that two years from now, when you have a 3Ghz machine, Diablo 2 will *still* take 100% of your CPU. It will be doing 200 fps, but will still eat the whole chip.

It seems like games ought to start clamping down on the processing. Perhaps stop at 30 fps, even if it could go faster. That way, if you''ve got a quick machine, it will only consume a percentage of the processor power. In todays multitasking machines, games should be more cooperative.

Take care,
Bill

Share this post


Link to post
Share on other sites
quote:
Original post by Stoffel
[ sarchasm ]
Yes, event-driven architectures for games totally suck. I absolutely love it when I tab-out of Diablo 2 while I''m in town (doing absolutely nothing) to check a web page for an item set and my CPU is pegged at 100%. Doing. Absolutely. Nothing.
[ /sarchasm ]


You don''t absolutely disregard events being thrown at your WndProc() unless you are...
I dont like writing COMPLETELY event based code, but i monitor important events, primarily through my own WndProc.

-----------------------------
The sad thing about artificial intelligence is that it lacks artifice and therefore intelligence.

Democracy is where you say what you want and do what you''re told.

Share this post


Link to post
Share on other sites
The problem with Diablo isn't that it's not event-driven it's that the game-loop/render-loop doesn't ever sleep. Which is just stupid - your thread is *going* to be swapped out whether you like it or not. You should Sleep(0) between frames, it lets you influence when you are swapped out - meaning you can minimize the likely-hood of being swapped out mid-render.
Ever played a game that had really choppy audio? It's partly due to over-agressive memory-bus-hogging video drivers, complex scenes, and because the bastards didn't sleep. Great my fps is 103 instead of 96, and the sound blows-chunks.

Once you have a sleep in there, it's easy to make it suck in a volatile DWORD for the duration, and voila, on the dreaded alt-tab, set the puppy to 10, OnFocus/once you can finally restore your surfaces set it back to 0. Atomically syncronized too.


...
btw, for an FSP, 30fps is _way_ too low - painful even.

Edited by - Magmai Kai Holmlor on February 19, 2002 12:56:54 AM

Share this post


Link to post
Share on other sites