![]() Here is the uncompressed file from the FRZ and here is the compressed file, from the ROM. If anyone here has binary file comparison software, could he/she look into the compressed and uncompressed level files for analysis? I know Kirby Super Star (SNES game) uses the same compression as Kirby's Dream Land 2 (Game Boy game) and Kirby's Adventure (NES game). Although I doubt it, it might be the same/similar compression as Donkey Kong Country 3. How does the game transfer the level data from the ROM into the complete block array seen in the save state? There are similarities, but I've never dealt with compression algorithms (except RLE) unless there's an automated tool to do it. Automated mapping in a way.īut in the end, I'm pretty confused. So, a thing worth mentioning is that the whole level with sprites (and possibly even bonus levels) are loaded all at once, so in theory, it could be very possible to make a program that reads the Save state of the level as input and spits out a complete map of the level as PNG. If you pay attention to the blocks with sprites, you'll get the idea behind the sprite flag bit. This is the level data in the FRZ (0x2660, $716 bytes long) overlaid on top of Blaziken's fantastic rip of the map: So, for example, $2E is the rooftop block, but $AE is the rooftop block WITH a sprite on top of it. If the bit is set, a block is printed but with a sprite on top of it. What I did next was compare the level data dumped to a KiGB (possibly every other GBA emulator too) save state, and found that one byte consists of STTT TTTT bits, where T means tile to use ($00-$7F) and S being the sprite flag. If the tile to use goes above $7F, the level breaks, but only in the ROM. Observe:Įach level has only $7F blocks to choose from. I tried $00, $01, $02, $03, all the way to $7F, screenshotting my way to a full tileset rip. Editing the first byte, for example, will change one of the cloud blocks to something else. It is compressed in a way that I have yet to FULLY document, but I've made some changes in the level already. More on that later.Īfter there bytes, the level data begins. And finally $BF, which has something to do with the sprite array. $0C, which is the height of level in 32x32 blocks (+2). $97, which is the width of level in 32x32 blocks. Here's what I've got.įirst of all, if you go to 0x5C001, you'll find three bytes. ![]() Wasn't until a few days ago when I think I made some serious progress. I know where Red Dwarf's level data starts and pretty sure where it ends but when it comes to editing it, I've always been kinda stumped. I've looked into DK元 in the past but only with relatively low success.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |