SpritesMind.Net

Zlib compresses rather well, for level data, etc.

Using miniz tinfl at -O3, the Genesis decompresses at 23.1 kb/s. It uses about 11kb of RAM. The optimized implementation for the NES uses 1.2kb RAM, but as 11kb is not that much, and the C source was easy to port, I didn't try to reduce the RAM usage.

As the license is permissive, would there be interest in adding it to SGDK?

SGDK already include some compression schemes, aplib for instance is a multiple purpose. How does miniz compare to this one ?
I would like to add efficient compression/decompression capabilities in SGDK but i don't want to provide too much solutions so developers got completely lost in selecting the good one. Ideally i think 2 generic methods would be enough (1 providing fast unpacking with average compression level and another providing slow unpacking with good compression level).

aplib is closed source, and therefore I won't use it no matter how good it is. EDIT: This is for level data, and other user things, not for tile compression. It could be used to tile compression too, but I intended it to be exposed so the users can compress game-specific data.

Zlib is also industry standard, installed on practically every computer, while I had never even heard of aplib or uftc before coming here.

That said, zlib compresses better than aplib according to this link:
http://www.maximumcompression.com/data/summary_mf2.php

I did some quick optimizations, dropping the RAM use to 8.4kb.

Definitely interesting, it would be nice to lower ram usage as much as possible so we could use free space to store unpacked data Is the unpacking implementation heavy or not (i mean in code size) ?

It's a few hundred lines of C. On x86_64, the compiled binary size is 13kb.

edit: Built for the Genesis, it's 6.2kb.

I tuned the speed-memory tradeoff, now it takes ~4kb RAM but decompresses 1% slower.

That sounds really good =) I think i will redo compression stuff so i will only keep this miniz and probably another method for "live" unpacking.
I will also keep specific methods for tilemap and tile data compression if they really worth it
Thanks for pointing that out. I saw nanozip offers a very good compression rate and also good unpacking speed depending selected option. Still I believe nanozip uses advances compression methods out of 68000 scope.

cero wrote:aplib is closed source, and therefore I won't use it no matter how good it is.

Only compressor is closed source. What exactly you don't like in this fact?

@r57shell

A matter of principle. Closed source on a computer has both ethical and practical concerns (security); it can do all sorts of things and you have no way of knowing. Nor can you tune it, fix bugs, use it in ways the author didn't envision.

So in this sense I'd be more comfortable running closed source sw on an airgapped console, without network access, than on a computer where it may access/delete/modify my data, call home, or do all sorts of undesirable things.

Virtual Machine
or you can write your own aplib packer, as I did . But my reason was to ensure that it does maximal possible packing within unpacker code. And it figured out that it's not.

Hmm actually you can try contact author of aPLib

Yes, a VM would provide separation, but that's an incredible PITA for something like this, that I don't want to use in the first place.