Sonic 2 Disassembly

Probably... try to deal with Hivebrain's one? Someone said that constants in SVN is unnecessary crap, but Hivebrain's disasm doesn't have it. Only mappings and some pointers are separate, but it's normal, isn't it? But it on its own is still needed in work, with a lot of unnamed labels since IDA (I could be wrong) and it also needed to be more commented. Please, correct me if I'm wrong.

 

Hivebrain's Git disassembly is a fucking mess and nobody should be working with it. He thought it was okay to release that but remove all references to old labels, so if you were trying to work with it and you needed to know the equivalent from the 2005 disassembly, you'd have to look for everything yourself instead of just getting a solid answer through the current disassembly.

What that disassembly needs is redone from the ground up (so working your way from 2005 and adding any useful stuff from the newer disassembly, as in the case with Stephen's new disassembly). All disassemblies as a whole could be easily improved, sharing a similar structure which would make working with them a lot more easier, however with everyone having differing views on how everything should be laid out, it'll never happen.

 

All this trouble, and the S3K disassemblies are still unlabelled piles of crap

 

That is actually a great idea, I think I might just do that.

I think I'll build the disassembly up using the Xenowhirl disassembly, and then add support in once it's done for the Git variable setup. I think at the moment it's more important to bring an ageing disassembly up to date for the people that hate the Git one, and then worry about making it universal at the end.

If this disassembly ends up being well received, then I may look at doing the same for a Sonic 1 disassembly in the future, unless somebody already does it first. I think S3K is definitely worth a look as well.

 

I'll say it again. If you want the address of some RAM, put a fucking 'trace' macro in front of its ds.x, or maybe just add comments listing the address, like how the code labels list their previous names. In fact, I had a half-complete realisation of that, most equates were commented with the original addresses, but I discarded it and never uploaded it because I didn't think it was needed; I didn't think anyone was that helpless. Guess I was wrong.

But the +/- do suck. There's nothing that those vague things can do that a descriptive local label can't. And we lost the historical labels for those things. Great.

 

You don't need to put a trace macro in every time you want a variable's address when you can generate a listing file that gives you all of the addresses. You could also generate a map file that doesn't include the entire source code, only line numbers and symbol values, but that slows down assembly a lot.

 

I actually like these, but only the ones when I add them. The old historic labels that have been replaced with the +/- can indeed go. You may have seen my priority guide where I show you five labels for xenowhirls' discount and then for SVN, I had to say "search this line".

 

The pluses and minuses are quite an odd idea to me. Who decided to add them? What benefit do they have over easy to search for labels? I don't see any benefits to them, and while I can wrap my head around the idea, the fact that they even exist is rather perplexing in my opinion.

 

The only use I find with them is to save you from making up new names for labels all the time when adding your own code.

-
addq.b #1,(RAMADRESS).w
bra.s +
nop
+
addq.b #2,(RAMADRESS).w
bra.s +
nop
+
addq.b #3,(RAMADRESS).w
bra.s +
nop
+
addq.b #4,(RAMADRESS).w
cmpi.b #$C,(RAMADRESS).w
ble.s -
bra.s +
nop
+
; etc...Rather than make a new label for each of them +'s, I rather just use the +. Branching to a + will branch to the very next + label, whilst - will do the same but go backwards. You can have as many +/- labels as you want.
Who's idea it was to replace the original labels with +/-, I don't know, as I find that irritating. I only use +/- when making my own code, so I don't have to be imaginative with label names (seeming as you can't have the same name as a label twice).

Anyway, back on topic...

 

Regarding equates and the way that Xenowhirl 2007 disasm was made... Personally I don't think I'll ever get used to


    move.w    #make_art_tile(ArtTile_ArtNem_Checkpoint,0,0),art_tile(a0)

Instead of


        move.w    #$6C0,2(a0)

or


Sonic_Jump:
    move.b    (Ctrl_1_Press_Logical).w,d0    
    andi.b    #button_B_mask|button_C_mask|button_A_mask,d0 ; is A, B or C pressed?

instead of


Sonic_Jump:                ; XREF: Obj01_MdNormal; Obj01_MdRoll
        move.b    ($FFFFF603).w,d0
        andi.b    #$70,d0        ; is A,    B or C pressed?


Most likely it's because I've been using Hivebrain 2005 disasm for a (long) while. But I do recognize that it is quite useful for beginners, as that way makes it easier to learn that RAM addresses $F602-$F606 (iirc) are used to read joypad 1. I agree with Cinossu: make two versions, one with equates, the other one without equates.

Another thing that I dislike and keeps me from using SVN/Mercurial/Git is that EVERY little thing gets splitted between a bunch of files on a bunch of folders, which is specially annoying if you need to mass replace some code. I wouldn't doubt that they will get down to the point where even sonic.asm will have to include itself. :V

The way that the 2005 disasm works is pretty logical to me: certain indexes and DPLCs are on "_inc", animations are on "_anim" mappings are on "_maps". Pretty straightforward.

Good luck on your project, that might make me create a S2 hack someday!