Page 1 of 2

Bee52: Crashes depend on CHRRAM data

Posted: Wed Nov 21, 2007 1:27 pm
by griever
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:

Code: Select all

$E6CF:2C 02 20  BIT $2002 = #$20
$E6D2:50 FB     BVC $E6CF
$E6D4:A9 81     LDA #$81; this command is never executed
Strange thing, cause the difference only in GFX data loaded... :?: [/url]

Posted: Wed Nov 21, 2007 1:59 pm
by bunnyboy
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.

Posted: Wed Nov 21, 2007 10:13 pm
by tokumaru
What's so special about the compression used in this game?

Posted: Thu Nov 22, 2007 6:07 am
by griever
That code is waiting for a sprite 0 hit.
D'oh! I've read about it hundred times! Thanks a lot!
What's so special about the compression used in this game?
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.

Posted: Thu Nov 22, 2007 6:45 pm
by tokumaru
griever wrote:Dunno... I've never senn something like this before. I tried to ask 'bout it here.
Yeah, I remember that...
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?

Posted: Fri Nov 23, 2007 12:35 pm
by griever
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?

Posted: Fri Nov 23, 2007 4:42 pm
by tokumaru
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...
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...

Posted: Sat Nov 24, 2007 2:07 am
by griever
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...
That's the VERY beginning of the hell =)
I think my LZ compressor did better than that most of the time.
Maybe. BTW how about kirby's adventure tile map compression scheme? Have you seen it? Well, It's easy
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.
But quite effective (sorry, but I don't have ratios). And I've never seen working packer for ths game.
I just noticed the link is dead. If you are interested I can upload again, as soon as I find the exact file...
Why not? It's interesting...

Posted: Sat Nov 24, 2007 6:30 am
by tepples
Fact: RLE is nothing more than the special case of LZ with a 1-byte window.

Posted: Sat Nov 24, 2007 1:30 pm
by tokumaru
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...
Maybe. BTW how about kirby's adventure tile map compression scheme? Have you seen it? Well, It's easy
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.
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.

Posted: Sat Nov 24, 2007 2:27 pm
by tokumaru
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.

Posted: Sun Nov 25, 2007 1:19 am
by griever
Get the LZSS compressor/decompressor here.
Arright, thanks a lot.
If I have the time I'll take another look at that Bee52 code.
OK, also you can try this (sorry for shitty colors, but I have net problems, so just had to compess image).

Posted: Sun Nov 25, 2007 2:46 am
by tokumaru
griever wrote: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...

Posted: Sun Nov 25, 2007 6:22 am
by griever
What is this?
Ah, sorry... As I said, that I have net problems =)
Here it is

Posted: Sun Nov 25, 2007 11:16 am
by tokumaru
griever wrote:Here it is
Cool! Is everything here? This sure makes things easier!