Exercises

Exercise 15.1: Bitmap loop sprites

Open the gamedefender3d.cpp file and comment in this line

 //#define LOOPEXPLOSION 

Also search down for LOOPEXPLOSION and take a look at the code to see what you're commenting in. Then recompile and shoot some props and see what happens. You get a nice cSpriteLoop that flips through three bitmaps.

Also watch what happens to your updates per second in the status bar when you shoot something. To check if this is due to the bitmaps or to the cascade of prop fragments , you can comment the LOOPEXPLOSION back out, run it again, shoot something and watch the updates per second.

It turns out that, at least the way the Pop Framework currently implements them, bitmap sprites are a little slow in the OpenGL graphics. The slowdown for bitmaps in the Pop Framework is especially strong if the bitmaps happen to be close to the viewer and take up a lot of the screen.

Exercise 15.2: A very long world

Let's change the game so it's a long world that you're moving through. Instead of the enemies coming at you, you are flying through them.

To do this, go to the cGameDefender3D constructor and change the third argument to the call _border.set(19, 19.0, 41.0) ; put in something big like 400. Then comment out the line in the cCritterDefender3DPlayer constructor that begins setMoveBox . Instead we'll be letting the player have its default movebox be the same as the _border .

If you run this version, you'll see that the prop critters are too far away. What we can do about this is to change the cCritterDefender3DProp constructor to position the new props at a random location ahead but not too far away “ at a distance of, say, 30 “40 units down the z -axis from the player()->position() . This means plugging in new locorner and hicorner arguments for the randomizePosition call based on player()->position().

Another good change here would be to have the props die as soon as they are behind the player, rather than waiting for the BOX_HIZ flag to appear in a prop critter's _outcode .

It would also make more sense not to penalize the player when a prop gets by. Instead just penalize the player when a prop or a bullet hits the player. This move of course makes it too easy for the player, so we'd better put in some cCritterDefender3DProp critters to shoot at the player.

You might also want to put some kind of furniture on the 'floor' of the world, some fixed critters by which you can judge your motion. In addition, you could have the appearance of the sprite and rival critters change as you move further into the world.

Yet another change to consider would be to use some variation on cListenerCar or cListenerSpaceship so that you can 'drive' your player in a somewhat realistic fashion, with gravity having an effect upon it.