Odds and Ends
Great! You've mastered the fundamentals of PMG and have seen how it can be used to develop a two-player, arcade-style game. In this chapter you'll learn some additional programming kinks.
So far I've said that you can create up to four players and that each player has a missile. Well, as you'll soon see, it's possible to have five players.
There is a trade-off, though; you have to give up all of your missiles. In other words, if you want, you can use the missile memory area as a fifth player. To do that you simply add 16 to the value you would normally poke into the priority register.
Using the Priority Register. Remember the priority register? It is location 623. You set various display priorities by poking either a 1, 2, 4, or 8 into location 623. (To review, see "Setting Display Priorities" in Chapter 5.)
To help you keep track of what you're doing you might want to write the code like this:
Suppose you want your normal player (players 0 through 3) to appear behind all playfields. The usual practice would be to poke 4 into location 623. But suppose you want a fifth player. Assuming PRIOR is initialized to 623, how would you code this?
Setting the Fifth Player's Color. To specify the color you want for the fifth player, poke a number from 0 to 254 into location 711. (To review, see "Specifying Player Color" in Chapter 4.)
Moving the Fifth Player. Although some PMG programmers may have problems with vertical movement, it will be easy for you! Just use the same method you learned earlier. Here's an example:
This statement will cause the image contained in LEGS1$ to appear on the screen at whatever vertical location is specified by Y4. (Remember Y0 goes with player 0. Y1 with player 1, Y2 with player 2, and so on. Remember, too, that the fifth player is called Player 4.)
Horizontal Movement. Horizontal movement of the fifth player is not so easy. Each missile still keeps its own horizontal position register. So to move the fifth player horizontally (in one piece) you have to poke all four horizontal position registers. Assuming that you have all missiles set to normal width, you might do it like this:
All those POKEs add up and slow down the animation loop. So here's another case where a machine language routine might come in handy, but that's the subject of my next book.
Even though these separate horizontal position registers pose a speed problem, you still might use them to good effect. For example, you might "blow up" the fifth player and scatter his pieces all over the screen. Or you might mysteriously create the fifth player by gradually moving his various pieces together.
Collision Detection. Another consideration is collision detection. Each missile still has its own collision detection register. That could be interesting. For example, you might specify that your player is vulnerable only if he is hit in the right arm. (He couldn't be hit by a missile, of course, but he might be hit by a "laser" created with a DRAWTO statement. Or he might be hit by another player.)
So far each player has only one color. But if you want, you can overlap player 0 with player 1 (or player 2 with player 3). In the area of overlap, a third color will be produced. In effect, then, you can have a three-colored, animated object. To make this work, you must first add 32 to the value that you would otherwise poke into the priority register (location 623).
Let's try a problem to clarify that. Suppose you want your players to have priority over playfields. Normally, you'd poke 1 into 623. But let's say you want a fifth player and you also want to combine player 0 and player 1 to create a multicolored spaceship. How would you code the poke into location 623?
GRAPHIC SHAPE REGISTERS
Now let's turn to another topic: the graphic shape registers. So far we haven't needed these registers. That's because we allocated a special area in memory to contain the PM shape data. And as you will recall, we told ANTIC where this PM memory area was by poking the address of BUFFER into location 54279. (To review, see "PMBASE" in Chapter 4.)
Also, we set up what is called "direct memory access" by poking location 559 with an appropriate value. In addition, we specified the type of resolution we wanted by poking location 53277.
Well, if you use the graphic shape registers, you can bypass ANTIC, and you don't have to poke anything into locations 54279. 559, or 53277. Consequently, your PMG setup is greatly simplified.
But the graphics shape registers are not so great for animation. That's because each can contain only one byte of data. They are useful, though, when you want to display a player image the entire length of the screen. You might want to do this to highlight textual material or to create a special boundary for a playfield.
Here are the graphics control registers for each of the players:
The graphics shape register for all of the missiles is at location 53265. Even though each graphics shape register holds only one byte of image data, that byte runs the entire length of the screen. You'll see an example of these registers in action in a moment, but first I'd like to expand on DMACTL, the direct memory access control register at location 559.
You can specify different options using this register. In the chart below, just add up the options you want. Then poke the total into location 559. But note that you must pick only one of the first four options:
Value to Poke
1 (pick one)
Note: you won't be able to see the edges of the wide playfield unless you scroll off the usual screen.
As usual I will end this chapter with a sample program. The program illustrates the use of:
PMG in graphics mode 0
The fifth player
Playfield size selection
Overlapping of players to get multicolored objects
A simplified PMG setup (using the graphics shape registers)
If you have written programs in graphics 0, you may want to consider spicing them up with some of the techniques demonstrated in this program.
Return to Table of Contents | Previous Chapter | Next Chapter