don't click here

Sonic 1 Disassembly

Discussion in 'Engineering & Reverse Engineering' started by Hivebrain, Dec 26, 2008.

  1. RetroKoH

    RetroKoH

    Member
    1,662
    22
    18
    Project Sonic 8x16
    Small thing to note here,,, has anyone (seriously, mind you) considered homogenizing the nomenclature of various things in the 3 MD disassemblies, such as the variables, constants, some of the routines, and the like?

    I've taken up doing this for the Sonic 1 disassembly, renaming ALL constants to match Sonic 2 disassembly's naming scheme. Will do the same for Sonic 3K as well. It just makes it a lot easier for me to switch around and work on the different games.
    Would there be any interest/desire for this to be the case? and if so... perhaps I could give the renamed disassembly to one with write access and they can make a small update?
     
  2. jbr

    jbr

    Member
    70
    21
    8
    Good idea, although may I recommend something: keep all the old labels right by their new names as a comment. Whenever I'm using some particular disassembly, I always seem to have a different one to the tutorial or How-To that I'm using, which means all the label names are different. The more fragmentation we get with labelling, the less useful the SCHG becomes!
     
  3. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,742
    338
    63
    SonLVL
    All the time.

    Of course, to do that, you'd have to pick out the "best" labels from each disasm (I would pick Sonic 2's labels every time), and there's going to be someone who disagrees with your choices, if anybody still cares at all.
    Then of course, you have to update all the tutorials, and possibly some tools (SonLVL is forced to refer to certain sprite mappings by label).
     
  4. Hivebrain

    Hivebrain

    Administrator
    3,049
    161
    43
    53.4N, 1.5W
    Github
    I'm biased in favour of the S1 labels because I wrote them. The problem I see with the S2 labels is that a lot of them are too generic ("id" and "anim" for example). This is likely to cause issues if you do a mass text replace on them. I used prefixes in S1 specifically to avoid this problem, by making sure every label is a unique string.
     
  5. Spanner

    Spanner

    The Tool Member
    It'd certainly make porting a lot easier, although that ruins the fun in a way. I will admit that I used the SVN (or Hg now) version to port objects to Sonic 2, when you've got macros rather than numbers you know what you need to change. Doesn't mean I like using these disassemblies, I prefer the 2005 and 2007 disassemblies and I really see no reason to change that.
     
  6. RetroKoH

    RetroKoH

    Member
    1,662
    22
    18
    Project Sonic 8x16
    Then maybe it's best to leave it as is... too much of a headache, especially when people are used to a different scheme for a different disassembly.
    Me personally, I'll be using the Sonic 2 labels and such for my REV C disassembly hacks.
     
  7. MarkeyJester

    MarkeyJester

    Original, No substitute Resident Jester
    2,202
    432
    63
    Japan
    Due to the differentiation of individuals who started the source code disassembling, leading to very little communication, and years of burning the information into the minds of the opposing individual users, means that attempting to standardise the sources at this point is futile. I believe however, that whether or not standardisation is necessary, should be decided by what benefits you would receive from such action. If the only benefit is "now people can port code between the games", then perhaps it's more trouble than its worth, and we should look to covering more pressing issues.