Still kicking….

The holidays are over, and I’m trying to get back into the groove of programming this game. For one thing, I have been thinking about how I was going to handle graphic storage. Obviously the 8 SPR slots were not enough, so I had thought about going with GRPs and copying into SPR when needed. Turns out that wasn’t going to be enough either since I also I have to deal with storing the levels themselves. My plan from that point was to either make separate external GRPs that got loaded, and then load the individual sprites from there, or reformat all the sprites again to become 2-bit like they are on the NES (as opposed to 4-bit PTC is forced to use) and see if that would do it. The first choice would have gone against my plan for a single packaged game, and the second choice would have require a lot of extra work, as I’d have to rip and construct everything by hand, and then deal with sprites that used more than 1 palette slot. But then my brain juices began churning…

All these options had one thing in common. They were all uncompressed graphics that I would be dealing with. So, I got to work on a compressed format, similar to RLE (Run Length Encoding), but with a few options, and I think I concocted a few, one for 3-bit, and one for 2-bit. I couldn’t really tell you how much space I’d save with this overall, as it all depends on the complexity of the sprites, but examining the ‘Met’ sprite frame below, which at 32×16 pixels would be 256 bytes at 4-bit within PTC (or 128 bytes at the original 2-bit format) is reduced to 80 bytes with a combination of my 2-bit and 3-bit compression algorithms. So, a reduction of 37% from 2-bit? I think this will be worthwhile, especially since my decompression algorithms for these sprites may actually be faster than copying them uncompressed from GRP files (as they can only be handled one byte at a time).

met