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:

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.

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.

Dunno... I've never senn something like this before. I tried to ask 'bout it here.

Yeah, I remember that...

Quote:

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.

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?

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.

griever wrote:

start screen GFX: Comp-0x584 bytes; UnComp-0x9D0 bytes; Ratio- 1,78

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

Quote:

font GFX:Comp- 0x13F bytes; UnComp- 0x290 bytes; Ratio- 2,06

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

Last edited by tokumaru on Sun Nov 25, 2007 2:43 am, edited 1 time in total.

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

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.

Who is online

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum