Exercise 6.1: Timing the critter motions


Min speed (units/sec)

Max speed (units/sec)

Avg speed (units/sec)

Approx. seconds to move ten units





About six





About two

Get a watch with a second hand, start up Game | Defender3D, and time how long it takes a critter to move across the screen. Is it about two seconds? Now make the window very small, and time again. Now make the window big, add more critters by selecting Game | Large, and time again. Do you still get about the same speeds? Now try with Spacewar. Time the critter motions again. Try editing the cGameDesign::CRITTERMAXSPEED value in gamedesign.cpp and try that game again.

Exercise 6.2: Estimating sizes

When you try and estimate the BitBlt overhead and its effect on a program's speed, it's nice to be able to carry out the calculations in your head or with a paper and pencil. Some key facts to remember are the following:

210 = 1 K one thousand

220 = 1 Meg one million

230 = 1 Gig one billion

240 = 1 Ter one trillion

250 = 1 Pet one quadrillion

260 = 1 Ex one quintillion

How do we use this knowledge? Suppose you want to estimate the number of bytes in an 800 x 600 pixel screen image in 16-bit color mode (64K colors per pixel)? 800 x 600 x 2 is 480,000 x 2, which is about 1,000,000, which is a Meg.

You can use the information another way around as well. If you see a number close to 32,000, then you can think this is 25 * 1K, which is 25 * 210 , or 215. So a mode in which you have about 32,000 colors is a mode in which you use 15 bits per pixel.

How many bytes are used by an 800 x 600 display if you use the 'true color mode' of 24 bits per pixel? Give your answer in K or Meg.

How many bits per pixel are used if you are in what Windows calls 16,777,216 color mode?

How many pixels are in a display of size 1024 x 768? or 869 x 1152? How many pixels in a 1024 x 1280 display? How many bytes are needed for each of these images if you are allowing 65,536 colors per pixel? Give your answers in K, Meg or Gig.

Exercise 6.3: How to maximize the main frame

If you like, you can make your game program start out as a maximized window. As we mentioned above, this is actually unwise, because if someone is running their video card in a very high-resolution mode, then your runspeed is going to be unacceptably slow. But here's how to do it anyway. Try it out and see if it works.

Find the BOOL CPopApp::InitInstance() code in Pop.cpp, and comment in the first of the two code lines and comment out the second. Run the program. Note that now the window is maximized. But you can still bring it back to a default size by clicking the Restore icon box in the upper right corner of the frame.

//pMainFrame->ShowWindow(SW_SHOWMAXIMIZED | m_nCmdShow); 
    //Use this version if you want main window maximized. 
    //Use this version if you don't want main window maximized. 

Exercise 6.4: How to set the main frame to a specific size

Here let's look at the spot where our default main window size is set. The numbers are set using some statics.

BOOL CMainFrame::PreCreateWindow(CREATESTRUCT& cs) 
    if( !CMDIFrameWnd::PreCreateWindow(cs) ) 
        return FALSE; 
    // TODO: Modify the Window class or styles here by modifying 
    // the CREATESTRUCT cs 
    cs.cx = CPopApp::STARTPIXELWIDTH; //800; 
    cs.cy = CPopApp::STARTPIXELHEIGHT; //600; 
    return TRUE; 

Try changing the statics to 640 and 480, respectively.

Exercise 6.5: Why OnIdle returns TRUE for animation

Go into the CPopApp::OnIdle code and change the last line from return TRUE; to return FALSE;. Build and run the program. At first nothing moves, but then move the mouse around on the screen and look what happens. You're moving the whole world yourself! Each time the program processes some messages it calls OnIdle and generates a single call to animateAllDocs(dt). As long as you keep moving the mouse, the motion proceeds smoothly. To make the program update continuously on its own, you can add a call to OnIdlp that "fakes" a key press: PostMessageC::AfxgetMainWnd()->L getSafeHwnd(), WM_CHAR, Ø, Ø);

Exercise 6.6: Why we clear the background for animation

Go into the CPopView::OnDraw code in PopView.cpp and comment out the line _pgraphics ->clear(targetrect); This line erases the game area plus the rest of the game window at each update. Also comment out the pDoc->pgame()->drawWorld(_pgraphics, _drawflags);. This line fills the game area with the background color at each update. With these two lines out, your old sprites don't get erased. Run the program and look at the trails. Kind of nice at first, but after a while the screen gets too messy. If we did want to have critter trails a better way to do it would probably be to develop a cSpriteTrail class that inherited from cSprite, but which held an array of, say, a critter's most recent ten or twenty sprites, and then erased them.

    Part I: Software Engineering and Computer Games
    Part II: Software Engineering and Computer Games Reference