A while back i made a post about my monster catching game Ocimons. While development of that game is on hold indefinitely, I wanted to release a new version of the compression algorithm I made for monster sprites in the game. It is heavily based off the compression algorithm used in the gen 1&2 pokemon games for the same purpose.

This build is very in-dev, it is not token optimized and it may be a pain to integrate into a project as of now. My next goal for the project will be making a compressor-only cart to facilitate that end of the tool, and a lua file containing a minified decompressor that can be added to your project with a single include statement. After that id like to release a new version of the compressor with smarter compression, palettes, and encoding. Encoding will allow sprites to work better with the compression algorithm.

use

This algorithm is best suited for large sprites with a cell shaded style. Instead of using the actual colors of the sprite, you should use color 0, then 1, 2, etc (see image below for example). In its current state, compressing an image with only colors 14 and 15 would need a bit depth of 4, while an identical sprite using colors 0 and 1 will only need a bit depth of 1, greatly improving compression. In my game, palettes were applied before drawing.
To use this, id recommend downloading the cart, adding your sprite prepared to fit the above requirements, and editing _init so that mode=0 and store_image() contains the proper values. The string for the sprite will be saved to your clipboard.

store_image(w,h,d)

compresses sprite 0 of width w (1-16 tiles), height h (1-16 tiles), and bit depth d (1-4 bits per pixel). bitdepth is the bits per pixel of your sprite, so a sprite using colors <= 2 uses d = 1, colors <= 4 uses d = 2, colors <= 8 uses d = 3, and colors <= 16 uses d = 4.

load_image(str,sx,sy)

loads an mmc data string into the sprite sheet at tile sx, sy

performance

this is a 3x2 sprite prepared for compression as seen in the cart. If it was converted directly into bytes, it would fit into 384bytes. If 2 bits per pixel was stored instead of 4 this would be 192bytes. With MMC, it can fit into 78.5bytes, which is about 4.89 times more efficient than the raw image and 2.45 times more efficient than the 2bpp image. This example does not account for storing things other than the pixel data, such as height and width (1byte for all examples), bit depth (2 bits for 2bpp and MMC), and compression flags (1 bit per bit depth MMC).
Included is a screenshot of PX9 compressing the same sprite sheet. Its a bit unfair since PX9 stores the whole spritesheet, but PX9 stores it as 124bytes while MMC with non-pixel data stores it in 80bytes. That being said, my compressor is built for a very specific task and is able to take advantage of that while PX9 will most likely work better in more general usecases.

tool compression sprite