2600 compression
Now that Gingerbread Man is done, I am already starting to think about the next project, or more accurately, working on my previous project (Superbug.) Also, a few people tried out a demo cart of the game at NWCGE and it was generally well-received.
The biggest problem with the game, I think, is that the track data takes a lot of space. Right now, each 128x128 track takes up 2k, and the supporting data, like powerup locations and the code to read the track data fills out enough additional space that only one track can fit per bank. With 3 banks already nearly full of program code, I'd only have 5 tracks in a 32k game, which would get boring quickly.
The arcade game uses a 256x256 random track, made from pieces of pre-defined curves and straightaways, and a few pieces containing sand, an oil slick, and another bug parked on the side of the road. (I also made a MAME infinite time and invincibility cheats to help examine how the game works.) It probably would be possible to make my game work this way and it would solve the space issues.
I'd prefer the bitmapped tracks, the only way these will work with a good number of tracks is to use a 64k or larger board (e.g. EF bankswitching) and/or some sort of compression. A compression method would need to be fast, maybe even faster than reading bitmapped data. The decompressor shouldn't be cumbersome in size or cycles, it should compress at least 50%, preferably more, and should be fully capable of random access of compressed data without huge loops. Unfortunately, I know of only one compression scheme that can be adapted to have all of these properties - RLE.
My best guess is RLE would either need to have a fixed number of "runs" in a line, say 8 (currently 16 bytes per line are needed) so data could be accessed randomly and the only traversal is a check of the numbers in the set of "runs." This would unfortunately have a large number of unused bytes.
Or, put in a table of addresses that contain the start of each line, though this would need 256 bytes in itself for a 128-high bitmap. Still might reduce to <1k though.
Well, if not compression, I'd be willing to invest in larger boards, though I'd probably prefer something based on 0840 to simplify the bankswitching logic to use two TTL chips and a 32-pin EPROM (128K-512k.) Supercat had this to say about it:
Even a lowly 16V8 would have no problem supporting a 64-bank scheme with 08xx hotspots. A 22V10 could push it up to 256 banks. That would be a megabyte worth of code. The same result could be achieved using two common TTL chips (a 74HC00 and a 74HC373, or any of many other combinations). The advantage of 0840 is that it doesn't require programming a PLD before assembly.
Also mentioned was adding an EEPROM to a board, which is also a good idea for a number of reasons, but I'm not sure would be fast enough to handle the 4-way scrolling in Superbug.
41 Comments
Recommended Comments