+  RHDN Forum Archive
|-+  Romhacking
| |-+  ROM Hacking Discussion
| | |-+  Some info for Megaman X3 that might be useful to anybody who wants to hack it
Pages: [1]
Author Topic: Some info for Megaman X3 that might be useful to anybody who wants to hack it  (Read 2 times)
Jigglysaint
Guest
« on: October 19, 2008, 06:34:27 pm »

Yes we know about the level editor, but even if it does get finished, it won't help you hack the entire stages to make new levels.  However, I've done some searching, and I've managed to figure out some of the building blocks to levels that may not be known.

Level data has been figured out, so I will skip that.  Level order data is actually quite simple too.  How it works is that the game will grab several screens at a time in order from top to bottom.  Now each screen has a value, like any other games.  Screen 00 and 01 are reserved for open air and filler screens.  How it works is that it's basically RLE format, which means one byte is the length, and the other is the screen value.  Like I said, the game will grab several screens at a time.  If you choose screen $02 as a starting place, and the length is $04(length is first), you will load screens $02, $03, $04, and $05.  Notice it doesn't count from zero.  I think if you set the last bit on the length, it will repeat that screen over again.  It appears as if the level length is variable(needs checking), so one level may be horizontally larger than others.  The game keeps doing this untill it finds an $FF.

Scrolling data was harder to find, but I did find it.  At $!DE43, there is a list of pointers that lead to more pointers.  This first set is the list for each level, and each level contains a variable amount of scroll pointers.  This works with the sprite data, and basically in the sprite data, if the sprite type is $02, and the enemy/item type is $00, then the argument byte will be the index of the scrolling pointer.  So for example if you see $02 80 05 00 01, etc, then the 00 and 01 is the scrolling index value.

Now the scrolling data itself is difficult, and still needs cracking.  What I see as a pattern is that it starts with 8 bytes that look like co-ordinates for the scroll.  After that comes what looks like scrolling permission data, at least 5 of them I counted.  What each bit or byte means is still unclear right now.

One more thing I also noticed was that for Gravity Beetle and Blizzard Buffalo stages, the way the game handles the small changes is that it actually has duplicate levels in the rom and the game just switches to them.  What this means is that you can significatly alter the levels after a certain condition is met(although sprites do stay the same).  What's better is that while the list in the ASM is small(could be re-pointed), there are more than enough spare pointers to make duplicate levels for all of the levels.  Only thing is you need space to define them, and that would take up alot of room.  This does mean that the game can be expanded somehow, and heck maybe we can see massive changes.  Remember the only thing that doesn't change is the sprites(so that means scrolling needs to stay the same).
Pages: [1]  


Powered by SMF 1.1.4 | SMF © 2006-2007, Simple Machines LLC