Did you do the same for Keystone Kapers and the other games you're doing? I have to confess that I'm not so smart to read assembler code... besides that, I'm reading the source code you provided and trying to get how the compress/decompress works and also about the color/palette stuff that I still find it complicated to understand...
Just another question... do you use the same compress method for all the games? Or do you create a specific compress method for each one? Would you mind posting an example of how do you perform the sprite compress? I'm tired of trying making 4k games just using procedural graphics, I'm trying to incorporate sprites like you do in your games, but I'm not really able to figure out how to achieve a great compression of the graphics. Thanks!
I'll try update the Wiki with a discussion of various ways to add bit-mapped sprites to 4K games at some point when I have more time, but I'll try to explain the gist of it here.
Obviously, I do not want to promote piracy of intellectual property. But, if you want to borrow graphics and gameplay from Atari 2600 games, then the first thing you should do is install an Atari 2600 emulator and download the associated game ROMs. Google will show you the way if you haven't already done this step. At the very least, this will allow you to carefully the study the game that you are attempting to recreate.
The ROM files contain the compiled code and graphics data. Write a program that reads in a ROM file, one byte at a time, and prints out each byte on a separate line in binary. But, instead of printing ones and zeros, print X's and periods instead. Carefully study the results. You'll find the same upside-down silhouette sprites that appear in that assembly source file.
The Atari 2600 used rectangular pixels, with a 2x1 ratio if I recall correctly. So, each row of 8 bits actually represents 16 pixels on a computer monitor (each pixel repeating twice).
For compression and hardware reasons, each row is assigned only one color and the Atari 2600 game artists often did an amazing job with that limitation. The color palette is essentially in HSV color space as described in one of the links. For each row in the sprite, there is a byte somewhere else containing the associated color. Finding the color tables can be a challenge without decompiling the source. But, in the case of Pitfall, someone already did the work for you.
As for storing the graphics in a 4K game, you can take the bytes representing the upside-down silhouette sprites and the associated color table bytes and generate a Unicode String out of them. For instance, you can take the 4 bytes 0xDE, 0xAD, 0xBE, 0xEF and generate the String, "\uDEAD\uBEEF". You can reference each Unicode character within the String using the charAt() method. From there, it's just a matter of extracting the individual bits. But, if you were able to print out the Atari 2600 ROM as I described above, you should be able to handle that step.
IMO the thing to do for bitmap graphics is to use a small palette and don't try to be clever. E.g. use a 16-colour palette, but encode each pixel as a character in a string rather than trying to pack two pixels or four into each character. That way the pack200 compressor can do a better job.
That may be very true. You can try it either way. That technique probably works better for level maps as opposed to the bit-mapped graphics because levels contain a lot of empty areas.