 |
|
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
| |||
| Views: 88,440,214 |
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
|
04-20-24 02:29 AM |
|
| Guest: Register | Login | |||
| 0 users currently in ROM Hacking | 4 guests | 1 bot |
| Main - ROM Hacking - Mario & Wario | New thread | New reply |
| Raccoon Sam |
| ||
 Cobrat Level: 56 Posts: 634/672 EXP: 1379328 Next: 18848 Since: 02-19-07 From: Hi Last post: 3461 days Last view: 2692 days |
Remember this game? Probably not, but regardless, it's a Japanese SNES title released in '93 by Nintendo and Game Freak. It utilizes the SNES mouse and you control a fairy-like creature called Wanda with it. Your objective is to keep smashing things —from coin blocks to pidgits— with Wanda and make the blind player get to the end of the level.
Great puzzle games always need a level editor, so let's check this out. In 0x40000 you find 8 bytes; 08 00 08 04 92 06 00 20 . After that, it's a bunch of FFs and 00s and small amounts of other bytes... then some 2-byte values that gradually rise higher, like 08 62 08 63 08 64 08 65 08 72 08 73 08 74 08 75 08... and then, at 0x406DE, we find that 8-byte 'header' again: 08 00 08 04 E2 06 00 20. Exactly the same as before, but the 92 got changed to E2. There are numerous headers, I've written down a few, check this out: 0x40000 | 08 00 08 04 92 06 00 20 | level 1-1 0x406DE | 08 00 08 04 E2 06 00 20 | level 1-2 0X40E14 | 08 00 08 04 DA 06 00 20 | level 1-3 0x4153A | 08 00 08 04 A2 06 00 20 | level 1-4 0x41C2A | 08 00 08 04 AA 06 00 20 | level 1-5 0x42322 | 08 00 08 04 12 07 00 20 | level 1-6 We know these are level headers because altering them or the data after them willl screw up the level. Screw up a lot. Take a look at the ordinary 1-1: 
yo sup And after changing one byte. ONE BYTE. 
jeesssuusss chriiissttt So, I'm pretty confused here. The levels aren't loaded to RAM, so that kinda confirms they are compressed. The question is, what compression scheme..? Post if you've got anything regarding this up. I love this game. EDIT: Okay I got some new infos up(?) 
This is the tileset of 1-1.. take a look at the other bytes after the FF bunch, starting from 0x4040A: 20 08 21 08 20 08 21 08 30 08 31 08 30 08 31 08 4C 08 4D 08 4E 08 4F 08 5C 08 5D 08 5E 08 5F 08 6C 08 6D 08 6E 08 6F 08 7C 08 7D 08 7E 08 7F 08 42 08 43 08 44 08 45 08 20 08 21 08 46 08 47 08 52 08 53 08 54 08 55 08 30 08 31 08 56 08 57 08 62 08 63 08 64 08 65 08 72 08 73 08 74 08 75 08 42 08 43 08 44 08 45 08 46 08 47 08 20 08 21 08 52 08 53 08 54 08 55 08 56 08 57 08 30 08 31 08 62 08 63 08 64 08 65 08 72 08 73 08 74 08 75 08 E2 0D ... Now ignore every other byte... 20 21 20 21 30 31 30 31 4C 4D 4E 4F 5C 5D 5E 5F 6C 6D 6E 6F 7C 7D 7E 7F 42 43 44 45 20 21 46 47 52 53 54 55 30 31 56 57 62 63 64 65 72 73 74 75 42 43 44 45 46 47 20 21 52 53 54 55 56 57 30 31 62 63 64 65 72 73 74 75 E2 ... Now compare these bytes to their coordinates on the tileset field.. 20, 21, 20, 21, 30, 31, 30, 31.. that defines two full 'little' blocks. 4C, 4D, 4E, 4F, 5C, 5D, 5E, 5F, 6C, 6D, 6E, 6F, 7C, 7D, 7E, 7F... that's the GOAL sign. If you edit any of these, the changes are universal. Editing the 42 43 44 45 would change the top row of the dotted big blocks to something else. Physical contact is also embedded to the tile, so that isn't defined anywhere else. My best bet is LZSS or similar.. the key here is redundancy. ____________________ |
| smkdan |
| ||
 Ninji Level: 36 Posts: 216/238 EXP: 288500 Next: 19610 Since: 05-26-07 Last post: 4056 days Last view: 4005 days |
that's not really how it works generally: If a level is not loaded into RAM, it implies that it's stored in a very simple to operate on format in ROM since the game is going to constantly have to look up the data quickly, maybe just arrays of references to a meta tile set which you can class as compression but not in the typical sense. This was used a bunch in NES games because the RAM budget is really strained. If it pulls the level data right off the ROM without sticking it in RAM, expect something extremely simple. But considering the SNES has a generous amount of RAM it sounds odd, but the developers can do as they please. If level data IS loaded into RAM it implies compression because it's likely to be stored compressed in a format that is not friendly for the game to work in with (like LZSS), but is then compressed and placed in RAM for easy lookup for the game to get graphics and sprite interaction with level working smoothly. If it stores level to RAM you should expect (complicated) compression in ROM, otherwise expect something absolutely dead easy. Anyway the game is cool and its nice to see work on it. if I weren't all into this homebrew thing of mine I'd probably consider making a level editor. |
| Main - ROM Hacking - Mario & Wario | New thread | New reply |
© 2005-2023 Acmlm, blackhole89, Xkeeper et al. |
|
MySQL - queries: 42, rows: 64/64, time: 0.015 seconds. |