The Jump to WindowsWe've now eliminated the use of off-screen video pages and page flipping from our fish tank program. In fact, the only time we update video memory is when the GoFish() function copies the virtual buffer contents to the screen. By now, it should be apparent that this exactly the behavior we need in a Windows program. However, we still have some work to do. First, we don't set the video mode in a Windows program, so we need to remove the call to fg_testmode() and the two calls to fg_setmode() in the main program. Next, we need to change the way we create the virtual buffers. Instead of allocating the memory ourselves and using fg_vbdefine(), we use fg_vballoc(). Of course, we then remove the calls to farfree() or free() at the end of the main program. We then move these tasks into the WM_CREATE message handler in WindowProc(), and add the device context and default logical palette setup:
In the DOS versions, the GoFish() function displayed all the animation frames, looping until the user pressed Escape. We called it once from the main program. While we could do the same thing under Windows, it wouldn't be too Windows-friendly. That is, as long as GoFish() was looping, we'd effectively disable all Windows messages. The solution is to make GoFish() build and display just one frame of animation and call GoFish() repetitively from an animation-based message loop in WinMain(). This has the same effect as before without disabling the ability to process Windows messages. Finally, because GoFish() displays a single frame and then returns, we no longer rely on the Escape key to terminate the program. Instead, we let the user exit the program in the traditional manner for a Windows application. Now all that remains (at least from a code standpoint) is the addition of our standard WM_PAINT, WM_SETFOCUS, WM_SIZE, and WM_DESTROY message handlers and WinMain() function. Refer back to the Fishtank program to review these.
|
 
copyright 2001 Ted Gruber Software, Inc.