The Collision Registers
Matt Giwer
Collision registers allow you to detect overlaps between players, missiles, and other objects on the screen--an especially valuable feature for game programming.
When using player/missile graphics, the Atari Operating System sets aside 16 registers (memory locations) for determining collisions. These collision registers can be read to see if there has been a collision, and what the player or missile has collided with. This allows control of events or actions within the program--such as triggering explosions, for example. For complex games, we need detailed knowledge about the numbers in these registers.
Exactly what is a collision? In the player/missile graphics sense, a collision occurs when the CTIA or GTIA video display chip is directed to overwrite an ordinary screen graphic or a player/missile with another player/missile. As part of this overwriting process, the computer writes different numbers into its collision registers, depending upon what kind of overwrite has occurred. In other words, when two things are to be on the screen at the same place at the same time, a number will be written to these registers.
An important fact about a collision is that there must be an overwrite by at least one pixel, rather than as a ball colliding with a wall where touching is enough to be called a collision.
Also, the numbers in these registers will not return to zero during the vertical blanking period (the split-second a TV screen is blank between frames). The only way to return the collision registers to zero is to POKE a number into register 53278. This is called the HITCLR, for Hit Clear, register.
Refer to Table 1. This shows what happens when Players 0 through 3 collide with other players. The left-hand column shows the register number associated with the collision of the player. The Player 0 through Player 3 across the top are the ones being collided with. The values in the table are those returned after the collision. For example, if Player 0 collided with Player 1, then PRINT PEEK(53260) would return the number 2. Also, PRINT PEEK(53261) would return the number 1, because the players have collided with each other and both registers will have a number written in them.
Look again at Table 1. Since Player 0 cannot collide with itself, the value remains zero. When you POKE a number into the HITCLR register, this collision register returns zero and remains zero until there is a collision with a player other than itself. This permits a register test such as IF PEEK(53260)>0 THEN [SOMETHING] rather than using three test statements for the values 2, 4, and 8. Thus, if you do not need to know exactly which player has been in a collision, you need not test for it.
Another aspect of this register is that it returns the sum of the collision values. That is, if Player 0 collides with more than one other player before you POKE HITCLR, then the number in register 53260 will be the sum of the numbers. If Player 0 collides with Player 1 and Player 2, then the collision register will contain 6; with Player 1 and Player 3, then the value will be 10; with Players 1, 2, and 3, the value will be 14. Note that in this case, as in Tables 3 and 4, these numbers are generated by setting bits 0 through 3 in the registers. Thus, in a machine language routine, the state of these registers can be determined by using a logical AND with a compare (CMP).
Table 2 shows the register values resulting from collisions of players with playfields drawn with the BASIC instruction COLOR. Depending upon the graphics mode, these can be character sets (normal or redefined), or PLOT and DRAWTO figures. There is no requirement that these actually be different colors since the real colors are controlled by registers 709, 710, and 711 and can be set to the same value. The playfield graphic needs only to be drawn by the COLOR instruction. The graphic might even be the same color as the background, and therefore invisible. Because these collisions return different numbers, it is possible to have different responses depending upon the graphic collided with. Thus a room may have walls drawn with COLOR 1 and a door with COLOR 2. When the collision register value returned is 1, the player will not be able to pass through the wall, but when the value is 2, the player can pass through.
Tables 3 and 4 are similarly structured and complete the register information. All have the same general characteristics. The number is generated by the setting of bits 0 through 3 in the registers, so the returned decimal value is 1, 2, 4, or 8 if only one collision has occurred, or the sum of these numbers if multiple collisions have occurred. Note that since no two numbers add up to any third collision value, multiple collisions cannot be confused with single collisions. Even with multiple collisions there is always a unique number returned. These values will remain in the registers until HITCLR is POKEd.
Note also that several collision registers are not provided. Collisions between missiles and other missiles are not detected, nor are collisions among playfields. Nor, as in the case of player collisions, are there reciprocal registers for the other possible collisions. For example, there are registers to detect when missiles collide with players, but there are no reciprocal registers to determine if players have been hit by missiles. To some extent this dictates the character of the program. When a missile is fired, the missileregisters must be tested.
Another characteristic of these registers is that even though a collision can be described as an overwrite, the registers fill regardless of the priority between players and playfields that has been selected by a POKE into register 623, the shadow (duplicate) of 53257. Setting these priority registers allows players to pass in front of or behind playfields, to simulate three-dimensional movement. But despite the priority selected, the register will respond as though there were no priority. Missiles will respond the same as their associated players. Thus when two objects are to be on the screen at the same place at the same time, the registers will change whether or not you can see both of the objects.
The collision registers also fill with the same number from each collision. Thus, if Player 0 collides with three separate objects all drawn with COLOR 1, register 53252 will still contain the value 1. No matter how many times the player collides with the different objects, the value will remain 1, until it collides with a playfield figure drawn with COLOR 2 or 3 or until HITCLR has been POKEd. Although different COLOR collisions will result in the sum, multiple collisions with the same COLOR do not yield a sum.
This way you can draw several identical graphic figures with the same COLOR, and then PEEK the collision registers for player collisions. When a collision is encountered, the location of the player can be used to determine where, among the many identical graphics, the next action (such as an explosion) is to occur.
Table 1. These values result from collisions among players.
| Play0 | Play1 | Play2 | Play3 | |
| Player 0/Register 53260 | -0- | 2 | 4 | 8 |
| Player 1/Register 53261 | 1 | -0- | 4 | 8 |
| Player 2/Register 53262 | 1 | 2 | -0- | 8 |
| Player 3/Register 53263 | 1 | 2 | 4 | -0- |
Table 2. These values result from collisions between players and playfield graphics.
| COLOR 1 | COLOR 2 | COLOR 3 | |
| Player 0/Register 53252 | 1 | 2 | 4 |
| Player 1/Register 53253 | 1 | 2 | 4 |
| Player 2/Register 53254 | 1 | 2 | 4 |
| Player 3/Register 53255 | 1 | 2 | 4 |
Table 3. These values result from collisions between missiles and playfield graphics.
| COLOR 1 | COLOR 2 | COLOR 3 | |
| Missile 0/Register 53248 | 1 | 2 | 4 |
| Missile 1/Register 53249 | 1 | 2 | 4 |
| Missile 2/Register 53250 | 1 | 2 | 4 |
| Missile 3/Register 53251 | 1 | 2 | 4 |
Table 4. These values result from collisions between missiles and Players.
| Play0 | Play1 | Play2 | Play3 | |
| Missile 0/Register 53256 | 1 | 2 | 4 | 8 |
| Missile 1/Register 53257 | 1 | 2 | 4 | 8 |
| Missile 2/Register 53258 | 1 | 2 | 4 | 8 |
| Missile 3/Register 53259 | 1 | 2 | 4 | 8 |
Return to Table of Contents | Previous Section | Next Section
