To MFC or Not to MFC

There are certain constraints imposed by the execution environment of Windows CE programs, which I'll be repeating throughout this tutorial. Primary among these is storage. Microsoft has created a set of classes to ease the creation of applications, the well-known Microsoft Foundation Classes (MFC). Designed for database-style applications, MFC is generally spurned by game developers. One of the accusations is code-bloat. Why include the MFC .dll which takes up storage space on the Windows CE device, when much of it will remain unused? Well, for one thing, in all but the oldest Windows CE machines, the MFC .dll occupies rom, not ram. So there's no storage overhead. And if you plan on creating a suite of games, or series, they can all use the MFC and save some small amount of storage. Or they can devote space to data which would otherwise go to custom routines. Developing for Windows CE devices largely restricts you to using the GDI; the slow refresh rate of most small lcd displays means that you don’t have to "bang on the hardware", or writing custom draw routines, for your games.

MFC also offers two other advantages for some programmers. First is the C++ class structure it imposes on you. MFC was a great help for me in the transition from C to C++. It provided a logical framework to guide me until I could understand the concepts behind classes and object-oriented programming. It also shielded me somewhat from the difficulties involved in event-handling code. But MFC also provides another advantage: fast prototyping. Using the Visual C++ IDE, you can create a fully functioning Windows CE program without writing one single line of code. The drawback to this is that you must use the MFC document/view class system. For most games, the document class isn't particularly necessary, but it can be used to organize and access the data for a Windows CE game. While I personally wouldn't bother with MFC for Win9x games, I've chosen to go with it for Windows CE games.

Creating the Framework

We're going to create the basics of a Sierra-style pseudo-platform game. I decided to call it Wizkid. This will require placing a graphic backdrop, with foreground elements, on the display, along with a number of sprites (the basic engine behind any platform style game). So fire up the Visual C++ IDE, and create a new project, as shown in Figure 1. Choose to create a WCE MFC Application (exe). In the lower right corner, select the x86 configuration; this is not a permanent limitation, but as we're going to be targeting the emulator first for testing purposes, you might as well select it now. In the upper right, title the project "WizCE" and tell it to create a new workspace. Move on to the next dialog, as shown in Figure 2. Here it will ask whether you want a single-document or dialog-based interface; there's no such thing as a multi-document Windows CE program (another difference between Windows CE and Windows 9x). The single window of a Windows CE application occupies the entire display.

Figure 1 [zoom]	Figure 2 [zoom]

The next dialog, shown in Figure 3, is pretty much irrelevant. You'll want to specify whether or not you wish help file support or a toolbar-style command bar buttons. In Windows CE, the titlebar and taskbar have been combined into a single toolbar called the CommandBar. You may not use a command bar at all, so deselect the toolbar button option. As for help support, help files use the HTML format, not the standard Windows format, and so they’re fairly easy to create. Choose to support help; since you will most likely be distributing your game via the Internet, you'll be including text- or html-based documentation anyway, so you might as well incorporate them into online help. You should have no need for ActiveX, Winsock, or database support, so make sure all of these are deselected.

Figure 3 [zoom]

The following dialog, shown in Figure 4, has an important element for later. You should include source file comments (just because you can,) and be certain to select "As a shared DLL" for how you wish to use the MFC library; otherwise the entire thing will be statically linked into your code, bloating the hell out of it.

Figure 4 [zoom]

The final dialog, seen in Figure 5, merely gives you a summary of what you've chosen. Make sure all the settings are correct, choose OK, and let the compiler create a program for you. Once it has finished, check to make sure that you're targeting the right platform, as shown in Figure 6 (in this case, H/PC version 2.00). This is the version of the operating system that the emulator runs.

Figure 5 [zoom]	Figure 6

Go Fever

At this point, you can look over the class hierarchy, and try to get familiar with it if you're not already. You might also try a test compile. It should compile and run, (first build all, then select execute WizCE.exe from the menu.) If you get an error during the compile or link stages that has to do with files or libraries that it can't find, check your directories options. If you get an error during execution regarding files or libraries it can't find, first get the name of the file it's looking for, then search your system for the file. If the file doesn't exist, something went wrong during the compile/link stage. If you find it (and in this case it's usually a .dll file), copy it over to your emulation environment’s "windows" directory (I've run into this problem with MFCCE20d.dll.) When you're confident you have a working program, move on to adding the code which will create our game