Graphics Compression Formats

walker7 · Post by **walker7** » Wed Jun 12, 2013 11:56 am

Some games have unique or interesting graphics compression formats. What is your favorite graphics compression format for the Sega Genesis?

The Nemesis compression format is entropy-based, but it takes a long time to decompress. Files with many long runs of the same nybble are best for this format. It is also best in portions of a program when the time the decompression takes does not matter.

The Kosinski compression format, when used on tiles, compresses well when there are a lot of identical bytes or patterns in the tile. It is also best in portions of a program when the time the decompression takes does matter.

Some games use an LZSS compression format, which is a lot like Kosinski compression. Their bitfields are usually one byte long, and the length/distance pairs are up to 4,096 bytes back, and up to 18 bytes in length.

Tommy Lasorda Baseball uses a compression format like this:

The first byte tells how many common byte values there are in the tile.
For each common value, there are 5 bytes: The first is the common value, followed by a 32-bit field telling which bytes have that value.
After all common values are listed, the remaining bytes of the tile data are listed in order.

If tiles consist of only two colors at most, you can use just 8 bytes to represent the data. If tiles consist of three or four colors at most, you can use just 16 bytes to represent the data.

What about the compression formats listed here?
http://www.smspower.org/Development/Compression
Even though they're for the SMS and/or Game Gear, they can easily be adapted to the Sega Genesis.

If you find any other unique or clever compression formats, feel free to post them here.

djcouchycouch · Post by **djcouchycouch** » Wed Jun 12, 2013 1:38 pm

Does the SGDK have compression functions? I don't remember.

r57shell · Post by **r57shell** » Wed Jun 12, 2013 1:41 pm

I like LZSS for files when time does not matter.
And, bit-based RLE for other things.

ICEknight · Post by **ICEknight** » Thu Jun 13, 2013 3:35 am

Speaking of, Sonic Spinball seems to have a unique format for its sprites that I'm not sure if it's somewhat compressed or just undocumented.

Would be cool to have a decompressor/viewer for those...

Ti_ · Post by **Ti_** » Thu Jun 13, 2013 8:07 am

walker7 wrote:Some games have unique or interesting graphics compression formats. What is your favorite graphics compression format for the Sega Genesis?

The Nemesis compression format is entropy-based, but it takes a long time to decompress. Files with many long runs of the same nybble are best for this format. It is also best in portions of a program when the time the decompression takes does not matter.
.

I've tested some tiles, and LZSS compress better than Nemesis.

Well-known RNC one of the most powerful compressor. But it require memory = archive size to decompress. (LZSS often uses only 1kb). More powerful - aplib.

LZSS modification used in KOEI games, compress my tiles with same size as RNC

(I've download that packer from chief-net.ru)

If compress tilemaps, some types of them compress good with UMK3 packer. (with word sequence: 0000,0001,0002,0003 e.t.c)

Stef · Post by **Stef** » Thu Jun 13, 2013 9:23 am

SGDK does not have any decompression methods. I wanted to add them some time ago but i think it should be done carefully. The methods has to be fast so we can do real time decompression (in a frame timelaps) and the compression scheme should be well adapted for tiles.
Maybe that topic could be interesting to determine the best compression scheme (at least the best one in term of speed /compression / memory use ratio) so i could include in it SGDK. I would prefer to avoid multiple compression scheme if possible to keep things simple =)

sega16 · Post by **sega16** » Thu Jun 13, 2013 1:53 pm

Packfire has really good compression ratios
http://pouet.net/prod.php?which=54840
I use it when speed does not matter

djcouchycouch · Post by **djcouchycouch** » Thu Jun 13, 2013 2:03 pm

There might be need for different types of compression determined by use.

For example, you might want a compression type that decompresses fast if you're doing work within a frame, like uncompressing sprites for that frame. And you might use another compression type that compresses better (but is most likely slower) for lots of tile graphics that only change between scenes or levels. You can make the user wait, say, a half second and they'll barely notice but you can do a lot of decompression work during that short time.

Ti_ · Post by **Ti_** » Thu Jun 13, 2013 3:20 pm

sega16 wrote:Packfire has really good compression ratios
http://pouet.net/prod.php?which=54840
I use it when speed does not matter

Thanks, I checked it, compressed my tiles better than others, and even better than 7-zip. Don't know about speed.
'Tiny mode' better than zip.

Ti_ · Post by **Ti_** » Thu Jun 13, 2013 5:55 pm

Well , I've test it.
Packfire requires additional 15, 980 Kb of memory... and it's very very slow...
'Tiny' mode doesn't require it, but can't pack large files.

tomaitheous · Post by **tomaitheous** » Mon Jun 17, 2013 5:58 pm

15, 980Kb? I'm assuming you mean ram. I can't imagine the code/decompressor taking up that much rom space. It's no where near that on the 65x version for code length.

I've used aplib, packfire, and pucrunch for 65x and they are all within range of each other. I was working on an 8k compo and packfire ended up being the best choice, but normally I go with Pucrunch because I can control a lot of options of the compressor/decompressor (I can manually define the LZ window size, which I tend to do for circular buffer decompression to a port).

Ti_ · Post by **Ti_** » Mon Jun 17, 2013 6:55 pm

tomaitheous wrote:15, 980Kb? I'm assuming you mean ram. I can't imagine the code/decompressor taking up that much rom space. It's no where near that on the 65x version for code length.

Yes, Ram.
Example for genesis games: level tileset = ~30kb+ 16kb ("probs buffer") wanted by packfire (=18 kb for other game data)+ wait 10 second for unpack.

Useful? No, only in some extreme cases. Better make a 8 or 10Mb game if you have not enough space.

Huge · Post by **Huge** » Tue Jun 18, 2013 12:37 am

Ti_ wrote:
tomaitheous wrote:15, 980Kb? I'm assuming you mean ram. I can't imagine the code/decompressor taking up that much rom space. It's no where near that on the 65x version for code length.
Yes, Ram.
Example for genesis games: level tileset = ~30kb+ 16kb ("probs buffer") wanted by packfire (=18 kb for other game data)+ wait 10 second for unpack.

Useful? No, only in some extreme cases. Better make a 8 or 10Mb game if you have not enough space.

You could probably port Street Fighter Alpha 2 to the Megadrive with it, and it might still have less loading times than the SNES version.

Ti_ · Post by **Ti_** » Tue Jun 18, 2013 8:23 am

I made a sample roms with pictures compressed by aplib, packfire and lzss:
Sega_Pics_packed.7z
(if u can't download try IE or Opera, or get from dir download

Shows:
packed size (uncompressed size of all = 38,400 bytes.)
compressed %
unpack time in frames.
Press any button to see next picture.

packfire speed very different on various emulators. (kega ~10% faster than gens, regen ~10% slowly than gens).

I don't have any speed packers that used to compress characters sprites. If you have them, I can try to add them to rom.

sega16 · Post by **sega16** » Tue Jun 18, 2013 2:29 pm

You could check out https://github.com/sikthehedgehog/mdtoo ... aster/uftc
it is made for doing decompressing sprites.
Also he has another compression called slz that is more of a generic compression
https://github.com/sikthehedgehog/mdtoo ... master/slz

SpritesMind.Net

Graphics Compression Formats

Graphics Compression Formats

Re: Graphics Compression Formats