don't click here

Sonic R Hacking

Discussion in 'Engineering & Reverse Engineering' started by MainMemory, Dec 1, 2009.

  1. Infiniti

    Infiniti

    ↑ & ↓ & ↻ Member
    476
    0
    0
    UK
    Custom tracks I'm all for that, but the thought of adding characters that came after Sonic R takes away some of the magic for me. If someone was to rebuild the game in a new engine, my only request would be to keep post Adventure characters out of the game. Sure you can add Ray, Mighty, Chaotix, Fang, Bean and Bark, but leave it at that... + - And maybe Motobug (for Jim)   .
     
  2. InvisibleUp

    InvisibleUp

    friendly internet ghost Member
    139
    13
    18
    Well, this topic exploded.

    From what I can tell the problem with the models is that if they get too large, they run into the space in RAM set aside for the next models, meaning it crashes when it gets garbage data half way though the thing. Say this is your memory right here:

    Code (Text):
    1. [MODEL1SPACE][MODEL2SPACE]
    Model 1 space has to fit into the space set aside for it. If it was bigger, you'd get something like this:

    Code (Text):
    1. [Areallybigmodel]DEL2SPACE]
    And then the space for Model 2 gets overwritten when it gets loaded.

    Code (Text):
    1. [Areallybigmo[MODEL2 DATA]
    When the game tries to read the really big model, it crashes because a chunk of it is missing and the game has no idea what to do.

    [​IMG]
    It's easy enough. You just change every reference to Amy's behavior routines to redirect to Sonic's. These are easy enough to find with something like Cheat Engine. Only problem is due to the problem above there may be an issue with animations not loading properly.

    Well what's the fun in that? [​IMG] But seriously, it's not an awful idea. It'd certainly be easier, but the thing is that if I were to make a fangame based on the assets of Sonic R, I wouldn't be hacking Sonic R. I would be editing a fangame based on Sonic R. I know it's a minor detail, but there's a reason people still hack the Genesis games despite they know it well enough to replicate it and improve it on another platform. They like the excitement of taking something they've known for years and making it better. Sure, they could just make a fangame, but then it wouldn't be the original.

    Also by the time we'd figure out how to re-implement the complexity of Sonic R we'd probably have overcame half these hurdles just from knowing how the game works and how to work around it, thus making putting in all the effort to rewrite the entire game from scratch entirely pointless. But that's just my 2 cents.
     
  3. SpaceyBat

    SpaceyBat

    Member
    2,036
    309
    63
    United States
    Freedom Planet 2
    I'm in the same boat. I would go for the Sonic Fighters characters at most, + - and Motobug also isn't a bad idea at all considering its method of transportation   . New cars for Amy would also be neato.

    In any case, considering that this game has a legit PC port, I'm sure that it can be hacked wide open with diligence. I hope custom tracks with their own AI paths will be possible in the future!
     
  4. E-122-Psi

    E-122-Psi

    Member
    2,471
    612
    93
    I think it would be great to get the current roster balanced out first. Half of them aren't all that fun to play as and pretty much lose by default. How's about fine tuning the handling of Amy's car, or making Eggman/Eggrobo's missiles actually do something? Anyone else think Eggrobo was supposed to have unlimited hover as well?
     
  5. InvisibleUp

    InvisibleUp

    friendly internet ghost Member
    139
    13
    18
    Models. I know you want them. And now you can have them.

    [​IMG]
    DOWNLOAD

    I'd link you to The Models Resource, but as of right now only Sonic, Tails and Knuckles are on there and the rest are in the mod queue behind probably every Pokémon ever. I'll link you to my personal page where I've hosted them for the time being instead. Wait a couple days/weeks and they'll probably be on TMR if you don't trust my site for some reason. (And yes, I know Metal Knuckle's head in that picture above isn't connected to the rest of his body. I'm just too lazy to rerender it. :P)
    EDIT: They're on The Models Resource now. Disregard the above.

    Also, a fun fact for you: The gun on Eggman-Robo (or whatever is name is) has a mistextured bit near the trigger area, having the texture of Tails' eye instead. This error is not present in the Saturn version, but is is there in the PC and GCN versions. + - Also I claim no responsibility for the inevitable resurgence of Tails Doll creepypasta.  

    EDIT: Fixed the links.
     
  6. TheKazeblade

    TheKazeblade

    "Our Life is More than a Side-Effect" Member
    Yowsa, Metal Sonic sure looks derpy from straight-on.

    Great job at pulling these models! I've always had a soft-spot for Sonic's saturn-era model. It's a shame it couldn't be used for an honest to goodness 3D Sonic game on the Saturn. Maybe with these models, someone can do something in that vein.
     
  7. Retroman

    Retroman

    Member
    733
    2
    18
    Dat Eggman green screen though
     
  8. InvisibleUp

    InvisibleUp

    friendly internet ghost Member
    139
    13
    18
    Been a year since the last post? Dang. I should probably prove that I haven't been dead. Because trust me, I've been busy. I would've submitted something to the Hacking Contest, but as it turns out Sonic R does not really liked to be hacked. Literally everything is hard-coded. I've been working on a solution to that, but I'll show that off in another post later.

    For now, though, I'm going to show you a stupidly simple fix to a huge problem in the game. Specifically, the problem is that slopes do nothing to you unless you're on a very steep slope. This means that, for instance, the big curvy bit in Radiant Emerald has proper slope physics, but not the canyon in Resort Island. Sonic or whoever just plows straight though banked turns and the such without any care. (As Jontron puts it, "They programmed magnets into the walls!") This, obviously, is wrong.

    The fix for this is simple. When the game is calculating velocity changes, there's a section that deals with slope physics. This section is skipped if the slope the player is on is less than 0FFFFF138h. (This is, rough estimate, a 15 degree angle.) We can't get rid of this skip because otherwise Sonic loses his ability to spindash due to not having flat ground and, on top of that, he slowly slides off the starting line and down the hill at the start of Radical City. (It's actually kinda amusing to watch.)

    What we need to do is make it so that if the player isn't pressing forwards, slope physics don't apply. This solves the "magnets in the wall" problem while also avoiding the "sliding down the start line" issue. I'm also going to make it so slope physics never apply when the player is holding down, which fixes some wonky rolling/spindash issues. (Spindashing still might be broken, though. Can't remember off hand.)

    Now to the meat. To fix this, go to 0x00485E34 in the EXE. Change

    Code (Text):
    1.  
    2. cmp     word ptr [ebx+72h], 0 ; Jumping?
    3. jz      CharDiff_RollStart ; Skip if
    4. mov     eax, [ebx+0B4h] ; Skip if not on big hill
    5. sar     eax, 10h
    6. cmp     eax, 0FFFFF138h
    7. jle     CharDiff_RollStart
    8. mov     eax, [ebx+40h]  ; In water?
    9. sar     eax, 10h
    10. test    eax, eax
    11. jnz     short CharDiff_RollStart
    12. test    byte ptr [ebp+Input+1], 10001b ; Accelerating with fwd or button?
    13. jz      short loc_485E8C
    14. mov     eax, [ebx+84h]
    15. sar     eax, 10h
    16. test    eax, eax
    17. jg      short loc_485E8C ; Unknown
    18. mov     dh, byte ptr [ebp+Input]
    19. test    dh, 8           ; Pressing left
    20. jz      short loc_485E69
    21. test    dh, 80h         ; Pressing right
    22. jnz     short loc_485E8C
    23.  
    (bytes '66837B7200 0F84 87000000 8B83B4000000 C1F810 3D38F1FFFF 0F8E 73000000 8B4340C1F81085C07569 F645ED11 743D 8B83 84000000 C1F810 85C0 7F30 8A75EC F6C608 7405 F6C680 7523' @ offset 76220 in the EXE)

    to

    Code (Text):
    1.  
    2. cmp     word ptr [ebx+72h], 0 ; Jumping?
    3. jz      CharDiff_SlopeEnd ; Skip if
    4. mov     eax, [ebx+0B4h] ; Skip if not on big hill
    5. sar     eax, 10h
    6. cmp     eax, 0FFFFF138h
    7. jle     CharDiff_Slope_SkipButtonCheck
    8.  
    9. test    byte ptr [ebp+Input+1], 20h ; Presing down?
    10. je      CharDiff_SlopeEnd
    11. test    byte ptr [ebp+Input+1], 11h ; Pressing up/fwd?
    12. jne     CharDiff_SlopeEnd
    13.  
    14. CharDiff_Slope_SkipButtonCheck:
    15. test    byte ptr [ebp+Input+1], 11h ; Accelerating with fwd or button?
    16. jz      short loc_485E8C
    17. mov     eax, [ebx+84h]
    18. sar     eax, 10h
    19. test    eax, eax
    20. jg      short loc_485E8C ; Unknown
    21. mov     dh, byte ptr [ebp+Input]
    22. test    dh, 8           ; Pressing left
    23. jz      short loc_485E69
    24. test    dh, 80h         ; Pressing right
    25. jnz     short loc_485E8C
    26.  
    (bytes '66837B7200 0F84 0700000 8B83B4000000 C1F810 3D38F1FFFF 7D0E F645ED20 7471 F645ED11 756B 9090 F645ED11 743D 8B83 84000000 C1F810 85C0 7F30 8A75EC F6C608 7405 F6C680 7523' @ offset 76220 in the EXE)

    You might notice we lose the 'in water' check here, but considering it's physically impossible to have an underwater slope, it's kinda redundant.

    The only issue with this is that you can't really coast like this. Once you let go of the forwards button physics stops doing it's thing. An alternate solution is to never skip slope physics if the player's speed is above some value. I didn't implement that because I literally just thought of it 5 seconds ago, but it should be easy enough to do: just place a jump right before the slope angle check that skips past it if the player's forward speed ([ebx+44], I think) is greater than some value.

    By the way, this certainly is no magic bullet to fixing the game (you still run into the walls there in Resort Island), but it adds that little something that was missing.
     
  9. Azookara

    Azookara

    yup Member
    That actually sounds really dang fascinating. TBH I'd love to play a build of Sonic R with this fix when it gets to a point where you can do it. :)
     
  10. Laura

    Laura

    Brightened Eyes Member
    Yeah, I'd love to see more hacking of Sonic R. It's a pretty naff game but it's kind of charming nonetheless.
     
  11. InvisibleUp

    InvisibleUp

    friendly internet ghost Member
    139
    13
    18
    Guess what I've got~!

    [​IMG]

    [​IMG]

    [​IMG]

    [​IMG]

    [​IMG]

    Turns out, I had the spec figured out this entire time. I just forgot to read it when I was hacking together my converter. //forums.sonicretro.org/public/style_emoticons/default/specialed.png

    Of course, don't think this means custom levels now. We still have to figure out collision and AI and the metadata in the geometry file and all that fun stuff.

    I'll probably dump the tracks on the Models Resource soon, but if you want the converter today, it's here on my hideously neglected Github.
    Usage is simple enough, just run it through Python 3 with any .BIN track file and it should spit out an OBJ with the model. You'll have to define the textures manually (the texture list for each level in the EXE, not the file). but besides that it should be 100% functional.
     
  12. Now that those can be exported to OBJ, how long do you think it will take for somebody to import them into Generations for a sort of Sonic R HD version?
     
  13. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,758
    341
    63
    SonLVL
    Forget Generations, I want these in SADX!

    I don't suppose it would be possible to translate the collision data into a 3D model, would it?
     
  14. SpaceyBat

    SpaceyBat

    Member
    2,036
    309
    63
    United States
    Freedom Planet 2
    These would make wicked SADX stages, for sure. They even look like good thematic matches for Emerald Coast, Twinkle Park, Lost World, Sky Deck and Twinkle Circuit.
     
  15. Dark Sonic

    Dark Sonic

    Member
    14,631
    1,611
    93
    Working on my art!
    This should be the first level project for Sonic Lost World PC. These are awesome.
     
  16. Atendega

    Atendega

    Lesser Sea Sponge Member
    577
    0
    0
    Comfy couch
    Collecting insults
    This is incredible! I agree that these should definitely end up as levels in SOME other Sonic game.
     
  17. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,758
    341
    63
    SonLVL
    I think the hardest part of porting Sonic R stages will be the floor, because it's just a flat bitmap image. Someone would have to trace out the water areas, convert the floor shapes into triangles, and then most likely you'd add a floor and walls underneath the water areas, to simulate the underwater walking behavior.
     
  18. InvisibleUp

    InvisibleUp

    friendly internet ghost Member
    139
    13
    18
    By the way, looking at these models, there's apparently a reason Sonic R had such an awful draw distance.

    Here's Bob-omb Battlefield from Super Mario 64.
    [​IMG]
    It has 972 triangles.Reasonable number for the complexity of the level.

    Here's Resort Island from Sonic R.
    [​IMG]
    It has 22,445 triangles. That's over 20 times the amount Super Mario 64 has, and that's on the same console generation. (I'll stop spamming the thread with giant images now. :v:src="//forums.sonicretro.org/public/style_emoticons/default/v.png[/IMG])

    The reason? Compared to Super Mario 64, Sonic R can't repeat textures within a polygon. This means that the poly count has to be huge to have a good texture resolution. But if you notice, say, the pathways, the amount of polygons starts to get a bit overkill.

    Also, to answer MainMemory's question about the collision, I don't know, but probably. I haven't really looked at the format too much yet. (Been too busy messing with character attributes and actions and stuff instead.) From my haphazard attempts, it does seem to resemble a 3D model, as each bit of collision is one after another much like the model parts instead of in an array or something silly like that. It's a bit harder to reverse engineer the collision data because the only way to test it is to walk around in circles and figure out what's different, which gets real annoying real fast.
     
  19. Pexs

    Pexs

    Otherwise known as Spex Member
    That's a very interesting. I wonder why they couldn't repeat textures per polygon? That seems insane! Nice work getting out those maps, by the way. I'd love to see more technical posts like this, they're very interesting reads.

    That reminds me, I made a mod of the SanicBall engine a while back that used real animated models instead of balls. I betcha those Sonic R maps would fit right in. Gonna have to give that a shot later.
     
  20. ELS

    ELS

    Member
    233
    64
    28
    I have no idea how you guys even got the game running let alone modding.

    Cool stuff though, can't wait for Balanced Sonic R.