MFC vs WIN32 Compatibility w/ DX
Author
I''d like to hear some opinions on weither its best to use Win32 or MFC when doing system proging in DirectX?????
ph0ng^_^wh0ng
tanks u
MFC and DX doesn''t really get along very well...
Sure, you can make it work, but there''s a lot of
unecessary stuff you have to do, with class-inheritance
and all. Use standard Win32 instead.
--
MFC is sorta like the swedish police... It''''s full of crap, and nothing can communicate with anything else.
Sure, you can make it work, but there''s a lot of
unecessary stuff you have to do, with class-inheritance
and all. Use standard Win32 instead.
--
MFC is sorta like the swedish police... It''''s full of crap, and nothing can communicate with anything else.
I''m not going to badmouth MFC(there''ll be plenty of people along shortly that will do just that), but the bottom line is that you really dont need MFC to do a DirectX app. You dont need to know much Win32 either - just the basics of getting a window up.
MFC is great for what it''s there for, and obviously, that doesn''t include anything graphical except GDI 
--
MFC is sorta like the swedish police... It''''s full of crap, and nothing can communicate with anything else.
--
MFC is sorta like the swedish police... It''''s full of crap, and nothing can communicate with anything else.
I use WTL (switched after that Win32 vs MFC thread 
) and I''m happy with it. I can use inheritance on window classes, separate i.e. D3D & windows-related code from DI & windows-related code from the main app windows-related code and package each one into a nice class so that each one handles windows messages like it wants. Plus, I don''t have to write WinMain and WndProc every time, and I get goodies such as CString class that supportes Format and LoadString methods. Nice. I know there''s a performance hit when using Win32 wrappers, but I came to the conclusion that it''s not noticeable, and can be ignored. My code, however, is much cleaner and more reusable.
) and I''m happy with it. I can use inheritance on window classes, separate i.e. D3D & windows-related code from DI & windows-related code from the main app windows-related code and package each one into a nice class so that each one handles windows messages like it wants. Plus, I don''t have to write WinMain and WndProc every time, and I get goodies such as CString class that supportes Format and LoadString methods. Nice. I know there''s a performance hit when using Win32 wrappers, but I came to the conclusion that it''s not noticeable, and can be ignored. My code, however, is much cleaner and more reusable.
I''ve had very few problems working with DX and MFC - I''m not sure what problems people are referring to. The book uses the Win32 style because there was no point in spending chapters on MFC, but all my "real" code is MFC based.
What I typically do is create a dialog based app and either pass the dialog handle to CreateDevice or I create a class based on CStatic that resides in the dialog (if you want to do an app with windows controls as well as a viewport). After that, it''s very similar to the Win32 way. At most, the difference is maybe 10 lines of code...
If you want to continuously render, you have to have your own message pump in a render loop, but this is no different from the Win32 method. At worst, you end up doing pretty much the same thing either way, but you get the MFC classes when you use MFC.
In my experience (and depending on what exactly you want to do), an MFC app can be slightly cleaner and a little easier to manage.
Could anyone spell out how they "don''t get along very well"?
What I typically do is create a dialog based app and either pass the dialog handle to CreateDevice or I create a class based on CStatic that resides in the dialog (if you want to do an app with windows controls as well as a viewport). After that, it''s very similar to the Win32 way. At most, the difference is maybe 10 lines of code...
If you want to continuously render, you have to have your own message pump in a render loop, but this is no different from the Win32 method. At worst, you end up doing pretty much the same thing either way, but you get the MFC classes when you use MFC.
In my experience (and depending on what exactly you want to do), an MFC app can be slightly cleaner and a little easier to manage.
Could anyone spell out how they "don''t get along very well"?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
