don't click here

Sonic 2 SMS Hacking Tutorials

Discussion in 'Engineering & Reverse Engineering' started by Glitch, Oct 3, 2011.

  1. Glitch

    Glitch

    Tech Member
    176
    13
    18
    Since there has been some interest in S2SMS hacking recently, I've been putting some thought into writing a few tutorials. I've already started work on a tutorial for adding a new badnik and I'll be fleshing this out over the next few days. I'd like to get an idea about what tutorials people would like to see. It doesn't have to be specific to the Sonic 2 engine, it could be related to the SMS in general. So, what should I work on next?
     
  2. Ambil

    Ambil

    I want that heinous hedgehog hammered! Member
    Well, I have something. A few years ago, I made this topic, "Fall in a hole and don't die". There you can see that, if you manage Sonic to fall in a bottomless pit, he won't die and the game will get stuck.

    Any ideas for solving this problem, so we can create level layouts with functional bottomless pits? Perhaps we can do something like this:

    1) Read the height of the level from the level pointer, and store it in RAM.
    2) Check everytime Sonic moves downward, if his position is below the level's lowest line.
    3) If so, call the code for death.
     
  3. Espilonarge

    Espilonarge

    Member
    38
    0
    6
    Surprisingly, I remember that in Sky High Act 1, the bottemless pit near the very end of the stage had this glitch. At times I couldn't understand why, maybe it was a glitch caused by the invincibility (Sonic should "instantly" die instead of being able to walk across the bottom) or maybe there's something "hidden" like tiles you can't see.

    On another note, sadly I had given up on Aspect Edit because of one serious issue. If I edit an original rom file or compile a decompiled version of Sonic 2 (located here) after editing in Aspect Edit, sometimes I would end up with a completely unplayable rom (editing the original rom in Aspect Edit always causes the game to crash). Now I know for a fact that the level-size is correct (I make sure of this) but somehow either Aspect Edit is "altering" something it shouldn't (changes something in the tile/level data on it's own) or the compiler is bugged by misreading and inserting incorrect data in to the rom file (like incorrect tile/level tables).
     
  4. Ravenfreak

    Ravenfreak

    Feeling festive this year Tech Member
    3,171
    248
    43
    O'Fallon Mo
    Hacking Sonic Drift
    ^ I've never had any problems with Aspect Edit, and that goes for editing both Sonic 2 & Sonic Chaos. Did you accidentally save over the entire Sonic 2 ROM? (Meaning did you happen to name your file s2.sms?) Also with that bug in SHZ, I kept running and Sonic eventually died. :v:
     
  5. Ambil

    Ambil

    I want that heinous hedgehog hammered! Member
    That pit is filled with spikes, you just can't see them. There are no bottomless pits in all the game.
     
  6. Espilonarge

    Espilonarge

    Member
    38
    0
    6
    As I said, any changes made in Aspect Edit to an original Sonic 2 rom (saved over or not) always leads to an instant-crash when loaded (Fusion, Meka, etc). It was more of a "test" to see if the latest version of Aspect Edit fixed this issue but sadly it hasn't. There might be an issue regarding "version" types. I normally use a US version of Sonic 2 instead of the EUR and JPN versions but even then, there's more then one "version" of the US rom (tested with US v1.0, I haven't tried with US v2.2 yet).

    With the decompiled version, at first it seems to compile fine but after a few changes have been made in Aspect Edit to the Tile Table (just just graphics), the compiler that comes with the disassembly will spit out a "corrupted" ROM where the changes to the Tile Table have suddenly been muddled (Green Hills looks like it's lost the 32x32 Tile Table information but the level still acts "normal"). The prior version I used however did not play friendly after editing the level layout (Sonic kept falling to his death in Under Ground Zone Act 1) but I haven't tested editing levels with the current version. Deleting a compile and making a new one does not fix the issue.

    I honestly don't know which is the real culprit. Either Aspect Edit forgets to save certain bits of data ( or the compiler just doesn't want to play friendly.

    On another note, I wish the sprite/tile editor was a bit more feature-enriched. I'm so used to making sprite work in MSPaint that I keep forgetting Aspect Edit doesn't have a lot of features when editing sprites/tiles (especially the handy "undo" Ctrl+Z feature).
     
  7. Ravenfreak

    Ravenfreak

    Feeling festive this year Tech Member
    3,171
    248
    43
    O'Fallon Mo
    Hacking Sonic Drift
    I use version 1.00, the one that's included with Glitch's disassembly, but I'm not using the SVN version. I haven't had any problems. :\ (And I use Sonic Chaos version 1.20.)
     
  8. Espilonarge

    Espilonarge

    Member
    38
    0
    6
    I'm using Glitch's disassembly as well. The "scrambled" mapping issue seems to only happen if anything in a 32x32 mapping (eg = Green Hills Zone) was changed while using Aspect Edit upon compiling the rom file. It's almost as if the compiler doesn't know "where" in the VRAM the tiles are suppose to be located. Upon checking again, I know for a fact that the "tiles" are loading perfectly at $3000 in VRAM, but it's like the mapping is looking for the tiles somewhere else altogether (a couple of random tiles from VRAM but not the correct ones). This screenshot might be useful in this situation.

    [​IMG]
     
  9. Mikel

    Mikel

    Member
    I have a tutorial up my sleeve. Two years ago, I made a tutorial on how to add Dynamic Palettes to Sonic 2 SMS. It's simple, yes. But I figure that I would make a tutorial for that game. :)
     
  10. Glitch

    Glitch

    Tech Member
    176
    13
    18
    I'm not sure what's going on there. Can you send me an example of your corrupted mapping file? Can you check that the files are included in the asm file using ".include" rather than ".incbin"? Just changing mapping data shouldn't cause the game to crash.
     
  11. Espilonarge

    Espilonarge

    Member
    38
    0
    6
    I've gone and one-up'd the whole disassembly instead, I have no idea if something else is interfering with the compiler so it's better to make sure yourself.

    http://www.megaupload.com/?d=IQ9FGMUD
     
  12. Glitch

    Glitch

    Tech Member
    176
    13
    18
    The problem is that you're including the original binary file in the assembly. In order to change the mappings you'll need to use Aspect Edit's "Export to ASM" feature to generate the mapping source code. Next you'll need to change the relevant ".incbin" statement to ".include" your new asm file. For example, the GHZ mappings are included in bank 12. Open the includes/bank12.asm and change line 2 from '.incbin "mappings\ghz\mappings32_ghz.bin"' to '.include "mappings\ghz\mappings32_ghz.asm"'.

    I did this with your disassembly and the level loaded correctly (nice spring tiles, btw).

    You will still need to maintain the binary file since Aspect Edit can't load mappings from the asm file.
     
  13. Espilonarge

    Espilonarge

    Member
    38
    0
    6
    So THAT'S what that icon was for all this time. Even then if I did know what it did, I wouldn't have known about the ".include" function inside the bank files. There isn't any documentation included with the disassembly or Aspect Edit about those kinds of functions (until now).

    Thanks for the help Glitch. :)