Success compressing tiles?

[tepples]

EDIT: Strangely enough, it doesn't use CHR-RAM, but it does dynamically update the characters (sort of). I've noticed that there is a 32-tile area in the pattern table that changes depending on how the player character is moved, but does not update if the character continually moves in the same direction. So I'm guessing that the ROM is bankswitched depending on how the character is moved, and that that bank holds all of the animations needed for that movement

Just like Super Mario Bros. 3 and Kirby's Adventure, right?

[tokumaru]

This is also very, very common, in NES games.

[Bregalad]

In MMC3 games using CHRROMs at leat, because the CHR ROM switching size of 1kb is small enough to allow one whole kb to be "wasted" on the main player sprites, with the 3 other kbs of sprite patterns free for the other objects on screen, and then the player can be mazed from any CHRROM banks.
Alternatively, they could have one whole 2kb bank switched for the player and the other 2kb for other objects, allowing one whole 2kb bank to be used for all animations of a given player (without bankswitching), and allowing different protagonists to take place on the same screen at different times.

Older games using CHR-ROM (a.ka. MMC1 or CNROM) that would have done any of these techniques coudln't have used CHRROM unless a big amount of banks would be wasted, due to the whole 4kb/8kb switching.

[mic_]

Just out of curiosity I tried applying a delta-codec to the smb_orig pattern data and got a file that was 11956 bytes (that is, about 18% of the original file. or 73% if compared to a plain 2-bit represenation). It'd be interesting to try to implement the decoder in 6502 assembly sometime, since it's not very complex iirc (no multiplication/division needed).

[griever]

Speaking about compression, I've spent some time figuring out GFX compression in 'BEE 52'. Damn, that's pretty hard - Codemasters are genius of course, so I screwed up a little Anyway - what compression format does this game has? dunno maybe this will help - at least you'll learn about adresses...

[Dwedit]

Use rom corrupter to find where the data is stored in the file, then use breakpoints to find when the data is read and when its decompressed version is written to. Log what bits/bytes are read, and what bytes are written as a result.

[griever]

Hmm. I don't think, that it will give result... Baybe it will work on easy compression, but this algorithm is extremely complex. Output stream will become some kind of crypt or something... Reversing - is the only way I think.

[tokumaru]

Bump! Solution to the puzzle posted here. It was quite complex to figure out...