MFC Confusion

Posted by CodeRedd on January 27, 2014

In this segment of my journey toward a working game engine renderer, I encounter some refactoring and my first dose of MFC...

When I began the implementation of this project, I felt pretty comfortable. Some things were a little strange and new to me, like the use of HWND and other Windows API types that I hadn't seen before, but overall I felt like I had a decent handle on things. Until now, that is...

My evening's work started out pretty straightforwardly, with the refactoring of the connection between the renderer's DLL and its static library. Zerbst and Duvel noted in their book that their stated method of exporting some DLL functions to the accompanying static library is deprecated with the release of Visual C++ 7.0, and thoughtfully provided a solution: Instead of using a .def file, use _declspec(dllexport). Simple enough! 

However, the next topic that the authors tackled was the creation of a simple UI and codebehind to adjust graphics options such as windowed/fullscreen mode, resolution, and which graphics adapter to use (and here the book shows some age, since there's no mention given here of having more than one). I certainly approve of the authors' desire to make the engine more flexible by allowing the user to make adjustments on startup. In my mind, that's much better than picking some defaults and thereby making a bunch of assumptions about the user's goals and their hardware.

Following the book's directions to create the UI with MFC was fairly straightforward--create a few combo boxes, a couple radio buttons, some labels, and we're done. The codebehind, however, was another matter entirely. Many of the major functions, variables and API calls were abbreviated, so outside of the general skeletal structure of the DlgProc method, I was able to follow very little of what each line was doing. Expect a little longer than usual before my next update, as I think I should take the time to sift through this confusing chunk of code so that I can get a better understanding of how MFC works.

I should say, though, having recently attended a XAML talk at CodeMash, I certainly can understand why WPF is often such a preferred method of UI creation! The only reason why I'm not contemplating switching this UI to WPF is because I don't want to get sidetracked figuring out how to interop a C# codebehind with the C++ engine. I'm sure that I would be able to handle such a problem, but I've decided that that is a challenge best saved for another day.

Progress So Far: Refactored function export to static library, Created MFC Dialog for graphics options selection.

Coming Up Next: Work on understanding MFC, and then implement the meat of the DLL.


Leave a Reply

(Your email will not be publicly displayed.)

Captcha Code

Click the image to see another captcha.

Follow @CodeRedd11 View Culver  Redd's LinkedIn profileView Culver Redd's profile