Retroware's Latest Project

Click here for the latest version of this game.

Latest Update April 4, 1998!

Well, I have finally gotten around to working on my game again, and I must say things are coming along great! I've decided that the game will be a Supercharger game. This means more space for code and graphics. I wasn't really running out of space yet, but add in a scoring routine and sound and it wouldn't take long. Don't worry! Just because it's a Supercharger game doesn't mean it won't make it to cartridge format. I'm not using any of the Supercharger RAM, so a cartridge is still probable (don't e-mail me asking to reserve one yet!) You can play this game on PCAE 2.0b for DOS (you can get it at Dave's Classics).

I've been working on a new game for the 2600 now for some time. That's the thing with writing these games, you really have to be in the mood to sit down and crank out some code.

I started out earlier this year working on a demo I called the "multi-sprite demo." The purpose of this demo was to determine the feasability of writing a "smart" kernel (the main part of an Atari game that does basic stuff like draw the screen) that would allow more than the stock 2 sprites to be drawn on the screen anywhere without having to worry about conflicting sprites. This needs a little bit more of an explanation.

The hardware of the Atari 2600 has only 2 sprites. Now I know what you are thinking, "I've seen more than 2 sprites on the screen at once, I'm sure of it!" Well, you are correct, the beauty of the 2600 is that the sprites can be reused over and over on the screen, as long as a sprite's "copy" does not occupy the same horizontal space with its original. For example:

1a         2a
   2b         1b

is O.K. because sprite 1 is reused below the first copy of it and the same with sprite 2. The following:

1a   1b    2a
  2b          1c

would not be O.K. because two copies of sprite one (1a and 1b) overlap horizontally!

The solution to this problem is to draw sprite 1a and 1b on alternate frames. Well, the simple way to handle this situation is count the frames and draw sprite 1a on even frames, and sprite 1b on odd frames, but this causes the sprites to "flicker" on the screen. For what I want to do, I realized early on that flicker was a necessary evil, but I'd like to reduce it as much as possible. The way to do that is to have my kernel determine when sprites overlap, when this happens, the kernel would have to schedule which one of any number of overlapping sprites gets drawn on any particular frame. Now, going back to my example, let's see what happens if sprite 1b moves as such:

       1b
1a         2a
    2b         1c

Since no copies of a particular sprite overlaps another copy of the same sprite, there are no conflicts, so we don't need to alternate. That's exactly what I aimed to do with this demo.

I'm tired of typing right now, so I'll finish this up later :)