griever wrote:
That's the VERY beginning of the hell =)
Yeah, I gave up because it was getting hard to keep track of all the branches... maybe looking at a log of the executed instructions would make it easier to understand... as we could see exactly what happens for each bit read...
Quote:
Maybe. BTW how about kirby's adventure tile map compression scheme? Have you seen it? Well, It's easy
Quote:
It uses seven different kinds of compression techniques, which includes the common LZ-Copy,RLE, and uncompressed data methods. The remaining types are simply variations of LZ-Copy and RLE.
Sounds like what's used in SMW and many other SNES (and even the Pokemon games on the Game Boy, I think) games... is this it? This was pretty well documented. This seems hard to encode efficiently, as you'd have to try every type of compression for each byte and see what works best.
The compression schemes used in Sonic games are also very interesting (the Mega Drive ones, as the SMS ones just seem to use simple RLE). They have 3 or 4 different formats, each used in differenttypesof data (level maps, graphics, music, etc). The most interesting one is some sort of LZSS optimized to encode small runs ofrepeated bytes, IIRC. gotta check that out again.
Quote:
Why not? It's interesting...
I'll upload it to a more permanent place in a few minutes... The compression ratio for the CHR I tried was about 1.5 to 1.6... The decompressor written in 6502 assembly will output the data to $2007, but I should probably make a version that outputs to regular RAM.
tepples wrote:
Fact: RLE is nothing more than the special case of LZ with a 1-byte window.
You are right. The cool thing about LZ is that, being a step up from RLE, it has built-in RLE support.