nesdev.com

As I've said before this game has masterpiece compression for gfx, so I was lucky enough to expand ROM itself and overwrite uncompression code, so it could load plain data. As a result, I've got this. As you can see This patch changes Font loading part, so uncompressed font is now at 0x4D in ROM, so I've began to repaint it, of course... And BANG! Game Crashes! I couldn't believe it - I thought it was impossible. Arright - just open ROM in tile moelester or something and delete blank red(second color) tile(I mean, make it black) - you'll see. So, as far as I can say, the problem somewhhere near code:

Strange thing, cause the difference only in GFX data loaded... [/url]

That code is waiting for a sprite 0 hit. If you changed the graphics then the right pixels may no longer be overlapping so the hit never happens. You will have to check out the original game to see which pixels can't be changed.

What's so special about the compression used in this game?

D'oh! I've read about it hundred times! Thanks a lot!

Dunno... I've never senn something like this before. I tried to ask 'bout it here. There I've also included IDA Lising. I just couldn't figure out what it as by myself, so I've also asked at couple of forums - and nothing... Plus even if i could write unpacker, it would be much harder (impossible? =)) to write the actual packer.

Yeah, I remember that...


Compression is something that really interests me... but I don't have the patience to trace the decompression code... it seems like too much work! =) But, just for curiosity, since you seem to think the compression in this game is very efficient, can you give me an idea of how good it is? Do you have any compression ratios to share?

Well... As far as I know from Code/Data Logger:

start screen GFX: Comp-0x584 bytes; UnComp-0x9D0 bytes; Ratio- 1,78
font GFX:Comp- 0x13F bytes; UnComp- 0x290 bytes; Ratio- 2,06

Don't know... Is it good or bad?

I spent some time yesterday trying to figure something of this compression scheme out... but that's just too boring! I saw they had a function to load 1 bit from the input data, and another to read 2 bits. And depending on the values read they's read something from a table... but I got bored easily, and though I was just wasting precious time I could be working on my game.


I think my LZ compressor did better than that most of the time. EDIT: I think I was wrong about this. It usually did worse than that. Of course it really depends on the data...


Fonts should be easy to compress because usually they use only one of the bitplanes. I'm not sure about Bee52, but with such a good compression ratio I'd guess this is the case.

EDIT: I just noticed the link is dead. If you are interested I can upload again, as soon as I find the exact file...

That's the VERY beginning of the hell =)


Maybe. BTW how about kirby's adventure tile map compression scheme? Have you seen it? Well, It's easy But quite effective (sorry, but I don't have ratios). And I've never seen working packer for ths game.

Why not? It's interesting...

Fact: RLE is nothing more than the special case of LZ with a 1-byte window.

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...


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.


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.


You are right. The cool thing about LZ is that, being a step up from RLE, it has built-in RLE support.

Get the LZSS compressor/decompressor here. The host does not allow ZIP files, so change the extension from JPG to ZIP.

I tested it a bit, and I'm not so sure it performs that well anymore... This is just a generic compression algorithm, so it'd be no surprise if it didn't do very well with NES tiles.

I'm still thinking of a way to make better use of the 2D redundancy present in the tiles... generic compression algorithms are 1D, and will ignore that.

If I have the time I'll take another look at that Bee52 code.

Arright, thanks a lot.

OK, also you can try this (sorry for shitty colors, but I have net problems, so just had to compess image).

What is this? I only see a very tall image with a white-ish rectangle at the top...

Ah, sorry... As I said, that I have net problems =)
Here it is

Cool! Is everything here? This sure makes things easier!