don't click here

ASM Sonic the Fighters - Disassembly (and discoveries from it)

Discussion in 'Engineering & Reverse Engineering' started by biggestsonicfan, Jun 1, 2020.

  1. biggestsonicfan

    biggestsonicfan

    Tech Member
    1,629
    432
    63
    Not really. There's a lot yet to be understood about the makeup of characters, so skeleton data is a little weird, especially because the type definition for the skeletons seem to be "Not-Bark" or "Bark" which doesn't make all that sense to me so far.
     
  2. biggestsonicfan

    biggestsonicfan

    Tech Member
    1,629
    432
    63
    It has literally taken me this long to find where the used credits are stored. The unused credits have routines which share the same ROM space as the end-of-game cutscene... the used credits, however are stored in the "draw_vs_routines" where things like "YOU LOSE" or "GAME OVER" or "CHALLENGER COMES" routines get drawn...
     
    • Like Like x 1
    • Informative Informative x 1
    • List
  3. Tiberious

    Tiberious

    Yeah, I'm furry. Got a problem? Oldbie
    Hmmm... I'd imagine it's because Bark has non-standard proportions (long torso, long arms), and the rest are similar in proportion to each other.

    Maybe they don't actually have defined armatures as we know them today, and instead each piece has its 'joint' at the 0-coordinate of each component object?
     
    • Informative Informative x 1
    • List
  4. biggestsonicfan

    biggestsonicfan

    Tech Member
    1,629
    432
    63
    This is what happens when you give Bark the "Not-Bark" skeleton lmao
    sfight103.png
     
  5. Tiberious

    Tiberious

    Yeah, I'm furry. Got a problem? Oldbie
    Yep, that's about what I figured. You can see how the game is trying to put his arms and head at the 'standard' positions, but his torso object is so tall it obscures the head. I'm going to also go ahead and say I'd expect a normal character using the 'Bark' definition would look exploded, so no need to show that.

    My thoughts about the origin of a characters' component objects forming the 'skeleton' is just really spitballing based on the fact it's such an early 3D title, there didn't seem to be too many standards for how to do articulated character models. There was a lot of vertex animation and other silliness done with other games around the same time, and just maybe that's a possible answer as to why you can't seem to find anything explicit for joint positions on the characters. Maybe with the object viewer it might become a bit more apparent?
     
  6. biggestsonicfan

    biggestsonicfan

    Tech Member
    1,629
    432
    63
    To be perfectly honest, I don't think the skeleton data itself is a mystery anymore. I just don't understand where the data that forms the skeletons is pulled from.
     
  7. Tiberious

    Tiberious

    Yeah, I'm furry. Got a problem? Oldbie
    Uh... was that maybe the wrong post? Not sure how that related to this game.
     
  8. biggestsonicfan

    biggestsonicfan

    Tech Member
    1,629
    432
    63
    It's 100% related. The model handling aspects between the entire generation of Sega's Model2 hardware are identical. Skeleton and animation data are extractable from House of the Dead, however I don't understand where that information is pulled in Sonic the Fighters.
     
  9. biggestsonicfan

    biggestsonicfan

    Tech Member
    1,629
    432
    63
    In insanely massive news, I've started investigating the PS3 executable which is used to emulate Sonic the Fighters and lo and behold, it contains source level labels for functions/subroutines. And just moments ago, I discovered that it also indicates where these labels go. A massive update is going to happen to the disassembly in a bit, but it's going to take a little time to implement.
     
  10. Tiberious

    Tiberious

    Yeah, I'm furry. Got a problem? Oldbie
    Ah, bless you port devs. I imagine this will make things much easier to understand and work with.

    Since you're working with the PS3 version, what exactly did they do in order to make the changes they did?
     
  11. biggestsonicfan

    biggestsonicfan

    Tech Member
    1,629
    432
    63
    Well, to be honest, I don't know the PS3 version that well. As discussed a long time ago, the PS3/X360 versions both use the Japanese Sonic the Fighters base ROM for the game's program data. My theory was that the emulator altered the code in memory, but upon memory dumping in a PS3 emulator, the size of the ROM is shrunk, data is seemingly removed and inserted, and you can't plug it into a model2 emulator because it's riddled with invalid 80960 instruction codes (something the official emulator bizarrely ignores). I'm very curious as to how the changes work, Honey's data being fixed and the character select screen stuff, but I don't have the knowledge or resources to scratch beneath just the surface of the official emulator code..
     
  12. Tiberious

    Tiberious

    Yeah, I'm furry. Got a problem? Oldbie
    Okay, so they patch the ROMs after the fact, essentially. I figure a good Model 2 emulator could have scripts doing things like toggle characters on button press, fix glitches with Honey, etc. like the PS3/360 versions.

    I guess now the question is how much of it would be possible just patched back into the ROM? I imagine you could do something like an 'MK2+' where your goal is to have an enhancement that runs on hardware, right?
     
  13. biggestsonicfan

    biggestsonicfan

    Tech Member
    1,629
    432
    63
    Well, yes, and this is something I have been trying to do on my own, as I've fixed Honey's squished parts and title cards. And while it wouldn't be hard to just create a routine that sees if we're at the character select screen, if the current character is Amy, and the start button is being held to give us Honey, the fact is we don't know how the PS3/360 version is doing it.

    And while we know they patch the ROMs after the fact, seeing that the ROM in memory is not a valid (or even working) ROM is not very reassuring to detect what differences might have been patched into memory.
     
  14. Tiberious

    Tiberious

    Yeah, I'm furry. Got a problem? Oldbie
    Yep. That was that patch I was referencing. I kinda figured that unless it was in the ROM itself you wouldn't know much about what patches they were running or how they got the outcome they did on console.

    However, seeing that you have an arcade disassembly to work from, it's possible you might find a more elegant solution.
     
  15. biggestsonicfan

    biggestsonicfan

    Tech Member
    1,629
    432
    63
    It was extremely frustrating to see the memory dump all garbled, but I'm not about to learn PS3 executable reverse engineering from the ground up just to figure out what it's doing lol. I feel like I could guess and get the right results before I reverse engineer to the point where I find out exactly how the PS3 ver does it, LOL! :ruby:
     
  16. biggestsonicfan

    biggestsonicfan

    Tech Member
    1,629
    432
    63
    I realize I've been very very slow to push the labels to the disassembly repo, it's been a tedious project. The labels which came from the Sonic the Fighters PS3 executable were a 1:1 address match to the data. However labels seemed to have been cherry picked at random, and do not contain all labels used in the source code. Virtua Fighter 2 and Fighting Vipers also have these labels, and I am meticulously comparing routines and functions to best add labels to the Sonic the Fighters disassembly for as much official documentation to exist as humanly possible. The StF disassembly now has over 1,000 official Sega labels in it, but there's still probably 1,000 labels left for me to manually comb through to see if they match Sonic the Fighters or not.

    In related news, work on the Sonic the Fighters decompilation has begun. The disassembled code can now be built with GCC with an i960-elf target. The "main" and "main_loop" functions will be the first to be disassembled and once those produce 1:1 C equivalent code, the decompilation repo will be pushed to github.
     
  17. Tiberious

    Tiberious

    Yeah, I'm furry. Got a problem? Oldbie
    Does this mean that sometime down the line, I might be clearing some space on my SNES Classic to play a port with possibly more extras than the PS3 version?
     
  18. biggestsonicfan

    biggestsonicfan

    Tech Member
    1,629
    432
    63
    I would not say that is a reasonable expectation to have, no. If and when I get main and main_loop decompiled, the entire rest of the binary will also need decompilation for that. This does not include audio or graphics handling, as the audio is handled by a separate processor and binary altogether while the graphics are handled by proprietary Fujitsu DSPs. Getting a decompilation running on anything, even PC, other than the i960 hardware it was designed for would require a monumental effort.
     
    Last edited: May 9, 2022
    • Informative Informative x 1
    • List
  19. SANiK

    SANiK

    Tech Member
    413
    0
    16
    Great work on this! Though, you should upload even incomplete work. Hard drive crashes and other failures do happen.
     
  20. biggestsonicfan

    biggestsonicfan

    Tech Member
    1,629
    432
    63
    I have a few online backups of the IDA database, but I am really pushing to write an article about the discovery of the labels at the same time I push the updated disassembly.

    I am terribly backlogged :psyduck: