Page 1 of 4

Graphics Compression Formats

Posted: Wed Jun 12, 2013 11:56 am
by walker7
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.

Posted: Wed Jun 12, 2013 1:38 pm
by djcouchycouch
Does the SGDK have compression functions? I don't remember.

Posted: Wed Jun 12, 2013 1:41 pm
by r57shell
I like LZSS for files when time does not matter.
And, bit-based RLE for other things.

Posted: Thu Jun 13, 2013 3:35 am
by ICEknight
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...

Re: Graphics Compression Formats

Posted: Thu Jun 13, 2013 8:07 am
by Ti_
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 :o (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)

Posted: Thu Jun 13, 2013 9:23 am
by Stef
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 =)

Posted: Thu Jun 13, 2013 1:53 pm
by sega16
Packfire has really good compression ratios
http://pouet.net/prod.php?which=54840
I use it when speed does not matter

Posted: Thu Jun 13, 2013 2:03 pm
by djcouchycouch
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.

Posted: Thu Jun 13, 2013 3:20 pm
by Ti_
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.

Posted: Thu Jun 13, 2013 5:55 pm
by Ti_
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.

Posted: Mon Jun 17, 2013 5:58 pm
by tomaitheous
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).

Posted: Mon Jun 17, 2013 6:55 pm
by Ti_
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.

Posted: Tue Jun 18, 2013 12:37 am
by Huge
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.

Posted: Tue Jun 18, 2013 8:23 am
by Ti_
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.

Posted: Tue Jun 18, 2013 2:29 pm
by sega16
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