I've been teaching myself Python over the past couple of days. Why? Just because! I feel I need to spread my wings and learn new things. Anyway, I ported my Kid Chameleon compressor over to Python. Then I wrote a decompressor from scratch. Both are available below: Compressor -- http://www.4shared.com/file/YPgU9Zh1/kcc.html Decompressor -- http://www.4shared.com/file/-0pwnYbz/kcd.html This is a labor of love for me. However, I decided to post these for other people to try them for one simple reason -- the Kid Chameleon data compression is actually stronger than anything in the Sonic games. If someone wrote a decompression routine in 68k assembly for this compression format, that would be neat to see. Oh, and if you're a Windows user and you don't have a Python interpreter installed, I included an EXE in the "src\dist" directory of both zip files. Keep in mind that C code is always faster, so that compression and decompression might take a tad bit longer than expected. Also, do NOT attempt compressing large files. The Kid Chameleon compression key can only be 64KB. So to be safe, I recommend not compressing anything that is larger than 40KB. If the compressor just sits there and sits there for a good while, the file you're compressing may just be too big and is causing the program to endlessly loop. Any input you'd like to post, feel free.
Looking at the decompressor source... Can you next time put the source and binary distributions in separate archives? I mean, the program's source code itself is just three files making up 2.5KB, I don't think it was needed to include all of the Python source files... Anyways *back at reading code*
Out of curiosity, would this be suitable for use for decompression of data ingame, such as how Sonic 3 does things during act transitions? Or would it be more comparable to Nemesis compression in that usage, in that it would introduce a higher amount of lag due to a longer decompression time, (such as Sonic 1's level load time for example). Basically, what I'm asking, is if the compression is stronger than Kosinski in speed, compression ratio, or both, as the initial post just states that it's a stronger compression scheme, but does not detail in which ways.
It compresses shorter distances and lengths in less space, I really doubt it's any faster. How fast it runs depends on how skilled is the programmer, I guess, I should go recheck the exact format for Kosinski to tell you.
Sonic 3's water levels tell us that the game programmers had a way to count cycles for each instruction, so that thay could copy palettes and make that depth surface effect you can see in Angel Island Act 1 and 2. What we need is a program that can encode packages high enough to fit within the allocated loading cycles allowed per frame. And for that, we actually need to know the allocation, or guess it by doing alot of testing. The amount of encoded data is not easy to know until the uncompressed data has actually been encoded (unless it is possible to count the exact encoded buffer and stop at the right time), so how do we trial and error the perfect packet size for an unknown size? The compressor probably needs to encode different packet sizes of the same data multiple time and do a binary search of each result until the closest packet has been found, where a packet is just below or equal to the allocated decode time for a game frame in Sonic 3 (found by counting the CPU cycles of the decode phrase). Then again. The Sonic's LZSS compression is not the strongest compression with support for streaming data.
I can tell you that Kid Chameleon loads it's levels pretty quickly, about the amount of time it takes Sonic 2 to decompress an act in memory. But the compression ratio can be better with Kid Chameleon's method. I would stress though that speed is heavily dependant on the software. That said, I have no real idea if Sonic 2 does a faster job at decompressing data than Kid Chameleon. They're close.
