Tao Te KaChing
Workin' the cash register of the Great Tao

Programming the Atari 2600, and Me - Part 7

The last post promised a discussion of collision detection.  Well, actually the last Atari-based post was regarding a portable Windows solution for 2600 development.  The Atari-centric post before that was a script for setting up a Linux-based 2600 development environment.  But before that, I'd promised collision detection, and now, here 'tis...

Collisions on the 2600 are extremely simple to conceptualize as well as handle.  A collision occurs when one object is drawn over another.  More specifically, when two objects have bits enabled on the same "pixel", you have a collision.  This distinction is important to make, actually, as two objects can easily sit on top of each other without throwing a collision flag.  Consider the diagrams below:



Notice in figure 1, the two players are shaped so that, when they are at the same location, none of their enabled bits overlap.  With a slight change to player 0 (figure 2), we should get a collision due to the two center pixels (the red squares).  The source code verifying this can be had here.

The Stella guide provides a diagram detailing the collision process (pg.34):


So basically, when two or more analog signals occur simultaneously during a scanning (scan)line, they will be “caught” by a series of AND gates, which feed through a multiplexer to their appropriate bits and collision address locations.  Per the Stella guide, two player objects, two missiles, the ball, and the playfield comprise fifteen different collision combinations, which are read (e.g. LDA) through data bits 6 and 7 (D6 and D7, or values 64 and 128, respectively) on (zeropage) addresses 00 through 07.  Below is the chart from the Stella guide showing this relationship.


Note, too, that more than one collision may be detected at a time.  Player 0 may be getting hit by Missile 1 the same frame Missile 0 hits Player 1, all while the Ball is colliding with the Playfield.  Per our chart above, we would check the D7 bit of CXM1P, CXM0P, and CXBLPF, respectively, to test for those collisions.  Again, refer to and play around with the source code previously mentioned above to get a feel for this.

Note, also, that the Stella guide recommends clearing the collision registers after doing your checks.  This is because the registers do not reset themselves, so if you are checking them, you'll want to ensure the values are “fresh” collisions, and not the remainder of a rastering several frames ago.  This is simply accomplished via a call to CXCLR.

On that note, I leave with Smiley racing diagonally across the screen while a missile shoots the opposite direction which demonstrates our articles to this point, including collision.  Needless to say, catastrophic events happen when Smiley meets the missile, so be sure to build it to end your sleepless nights wondering what happens!  Next we’ll look at incorporating sound, and we also need to look at user input (e.g. joysticks and paddles).  We'll then look at some algorithms to take care of common tasks, such as efficient horizontal placement of our objects, vertical drawing routines, keeping / writing a score, and anything else we can think of.