Some changes and fixes for Sonic 2

Has the bug in VS mode concerning the power up music changes staying on if the utilising player loses a life got a fix?

 

I could've sworn I made a fix for this at some point, but I can't find it anymore. Anyway, here's the fix:

Code (Text):

1. ; loc_3F926: KillSonic:
2. KillCharacter:
3.     tst.w    (Debug_placement_mode).w
4.     bne.s    .return
5.  
6. ;-------- bugfix --------
7. ; reset stats and music upon death
8.     move.w    #1,invincibility_time(a0)    ; make invincibility run out
9.     move.w    #1,speedshoes_time(a0)        ; make speed shoes run out
10.     cmpa.w    #MainCharacter,a0
11.     bne.s    .p2
12.  
13.     tst.b    (Super_Sonic_flag).w
14.     beq.s    .notSuper
15.  
16.     move.b    #0,(Super_Sonic_flag).w        ; remove super status
17.     move.b    #2,(Super_Sonic_palette).w
18.     move.w    #$28,(Palette_frame).w
19.  
20. .notSuper:
21.     jsr    (Obj01_ChkInvin).l    ; remove player 1's power ups
22.     bra.s    .kill
23.  
24. .p2:
25.     jsr    (Obj02_ChkInvinc).l    ; remove player 2's power ups
26. ;---- end bugfix --------
27.  
28.  
29. .kill:
30.     clr.b    status_secondary(a0)
31.     move.b    #6,routine(a0)
32.     jsrto    (Sonic_ResetOnFloor_Part2).l, JmpTo_Sonic_ResetOnFloor_Part2
33.     bset    #1,status(a0)
34.     move.w    #-$700,y_vel(a0)
35.     move.w    #0,x_vel(a0)
36.     move.w    #0,inertia(a0)
37.     move.b    #AniIDSonAni_Death,anim(a0)
38.     bset    #high_priority_bit,art_tile(a0)
39.     move.w    #SndID_Hurt,d0
40.     cmpi.b    #ObjID_Spikes,id(a2)
41.     bne.s    .playSound
42.     move.w    #SndID_HurtBySpikes,d0
43.  
44. .playSound:
45.     jsr    (PlaySound).l
46.  
47. .return:
48.     moveq    #-1,d0
49.     rts

The changes are between the two bugfix comments. The only other thing I changes was replace the nameless temporary symbols with named local symbols. As a bonus, I threw in a Super Sonic detransformation.

 

You probably did, but this is a hard to track gold mine of fixes now. :P

 

If anything, it's hidden away on an old hard drive somewhere. I have at least one old disassembly somewhere with a bunch of bugfixes that I never published.

 

Here is one more design choice change that can be made.
Extending the limit to how many frames Sonic, Tails or Knuckles can have!

Now, this is a bit limited due to how the animation subroutine for player characters works, but it does allow for more frames than what the game normally allows.
In this example, I will be using Sonic. However, this can be applied to Tails or Knuckles as well.

For Sonic, locate the label

Code (Text):

1. SAnim_Do2

now, look for a line that reads

Code (Text):

1. cmpi.b    #$F0,d0

Change this to

Code (Text):

1. cmpi.b    #$FD,d0

This will allow for 12 more frames of animation!

Edit: Actually, change it to $FD, as this is supposed to be the number AFTER the max amount of frames. Therefore, setting to $FD allows for $FC amount of frames to be usable.

 

Tails on the title screen doesn't have its priority set during the fade-in, meaning a few of his pixels will appear behind Sonic; to fix this, add "move.b #3,priority(a0)" under loc_130A2:.

 

Counts more as an extra than a fix, but for those who wanna add in Knuckles, there's an INCREDIBLY easy way to add in some exclusive shortcuts for him. The breakable wall from Sonic 1 (obj3C) conveniently still exists in Sonic 2 unused. When you've added it to your level route and mapped it to some new art, go to it's routine and make this edit in loc_15DAE:

Code (Text):

1.  
2. loc_15DAE:
3.     lea    (MainCharacter).w,a1 ; a1=character
4.     cmp.b     #$XX,(a1)    ;is player Knuckles? (replace XX with Knuckles' obj number)
5.     beq.w    Smash_Things
6.   ;  cmpi.b    #2,anim(a1)
7.   ;  bne.s    return_15DAC
8.     move.w    objoff_30(a0),d0
9.     bpl.s    loc_15DC2
10.     neg.w    d0
11.  
12. loc_15DC2:
13.     cmpi.w    #$480,d0
14.     bcs.s    return_15DAC
15. Smash_Things:
16.     move.w    objoff_30(a0),x_vel(a1)
17.     addq.w    #4,x_pos(a1)

This will change so instead of recognising Sonic's ball form, it will just recognise Knuckles only and let him plow through the wall.

 

Warning! Making objects continue to move after dying causes Sonic to continually die on the lava collision object (i.e. he dies and bounces on it forever). To be safe, add this above the Debug Mode check:

Code (Text):

1.     cmpi.b    #6,(MainCharacter+routine).w    ; is Sonic/Knuckles dead?
2.     bhs.s    +                ; if yes, branch
3.     cmpi.b    #6,(Sidekick+routine).w        ; is Tails dead?
4.     bhs.s    +                ; if yes, branch

 

There is an asymmetry between left and right when braking on all Genesis games (S1, S2, S3, S&K): when you start braking, the skidding animation is triggered when you are above 4.5 pixels/frame going right, or 3.5 pixels/frame when going left. This can become particularly noticeable if you increase the top speed of Sonic and test underwater.

So here is the fix for S1, S2, and S&K disassemblies: first, go to the following locations and find the code shown:

• S1: loc_130BA, loc_13120
  
  Code (ASM):

  1.         move.b    obAngle(a0),d0
  2.         addi.b    #$20,d0
  3.         andi.b    #$C0,d0
• S2: Sonic_TurnLeft, Sonic_TurnRight, Tails_TurnLeft, Tails_TurnRight
  
  Code (ASM):

  1.     move.b    angle(a0),d0
  2.     addi.b    #$20,d0
  3.     andi.b    #$C0,d0
  4.  
• S&K: loc_11438, loc_114BE, loc_14C62, loc_14CE8, loc_1746A, loc_174F0, loc_3559E, loc_35620
  
  Code (ASM):

  1.         move.b    $26(a0),d0
  2.         addi.b    #$20,d0
  3.         andi.b    #-$40,d0
  4.  

Now change all instances of d0 to d1 in the code shown above. That is it, the bug is fixed. Both left and right will now trigger skidding animation when braking above 4.5 pixels/frame.

What is going on is that the ground speed/inertia is stored in d0. When the data for ground angle is for this fragment, it overwrites part of the value for inertia. Right after this code fragment, there is a check to see if the character should brake (this happens only for shallow angles), and right after this, there is a check for ground speed/inertia for braking. So the braking check is done after the register is partially overwritten. And the reason why it is 4.5 pixels/frame instead of 4 pixels/frame is because 1 frame's worth of deceleration is applied before the comparison.

 

Another asymmetry, this time between left and right: take a look as these diveboard springs:

No matter how hard you try, you can never get a launch off the left-facing diveboard with the same speed you can from the right-facing one. The code that causes this is here:

Code (ASM):

1. loc_2645E:
2.     move.w    x_pos(a0),d0
3.     subi.w    #$1C,d0
4.     sub.w    x_pos(a1),d0
5.     neg.w    d0
6.     btst    #0,status(a0)
7.     beq.s    loc_2647A
8.     not.w    d0
9.     addi.w    #$27,d0

The reason for the bug is that it misplaces the characters relative to the board for computing the power of the launch. The fix is dead easy: take the last line:

Code (ASM):

1.     addi.w    #$27,d0

And change it to this:

Code (ASM):

1.     addi.w    #2*$1C,d0

 

Hmm, $1C times 2 is $38... but 38 decimal is $26 hex, which is only one off from $27.

Wonder what happened there?

 

You might have figured out what happened. Because

Code (Text):

1. not.w d0 == neg.w d0 ; subq.w #1, d0

they might have thought that they needed to add +1 to $38 to get $39. But then they forgot to write the $ in the code, and it became a $27 when reverse engineered.

As it turns out, that +1 gives the wrong result -- the last pixel you can stand on when the dive board is flipped will loop back to minimal strength launch, which is not what happens on the unflipped dive board.

 

Here is a CPZ boss crash: https://www.twitch.tv/videos/47314506

In case you are curious, this bug is of the "how the hell this boss even works" variety. To fix it, find this:

Code (ASM):

1.  
2. Obj5D_Pipe_Retract_ChkID:
3.     moveq   #0,d7
4.     move.b  #ObjID_CPZBoss,d7
5.     cmp.b   id(a1),d7   ; is object a subtype of the CPZ Boss?
6.  

and change it to this:

Code (ASM):

1.  
2. Obj5D_Pipe_Retract_ChkID:
3.     cmpi.b   #ObjID_CPZBoss,id(a1)   ; is object a subtype of the CPZ Boss?
4.  

What is the bug?

Register d7 is used by RunObjects routine to keep track of how many objects remain to be processed. Using it without saving before (as this code does) is a recipe for disaster. This piece of code runs when Eggman is retracting his pipe, and whenever an object with the same Y position as the next-to-last pipe segment. When this happens, the following may occur:

• if there remains more than $5D objects to process (ObjID_CPZBoss is equal to $5D in stock S2), some objects may remain unprocessed;
• if there remains between $59 and $5D objects, all objects will be processed, and some of the $200 bytes after will be treated as objets; if this area is clear, no ill effects will occur;
• if there remains less than $59 objects to process, primary collision, then secondary collision, etc., will start to be interpreted as object data, and you can get all sorts of crashes.

 

A double post, and another bug from the Chemical Plant boss. This time it is a graphical bug which was originally found and fixed by djohe; I am just sharing it.

After you beat the CPZ boss and the explosions finish, the boss is supposed to spawn a puff of smoke when blasting off. There is even code for it. However, due to a mistake in the code, it never appears. If you fix this mistake, you will see it appearing with incorrect graphics and palette, so we will fix that too.

Open your disassembly and find this code:

Code (ASM):

1.  
2. loc_2E9A8:
3.     movea.l Obj5D_parent(a0),a1 ; a1=object
4.     btst    #6,Obj5D_status2(a1)
5.     bne.s   +
6.     rts
7. ; ===========================================================================
8. +
9.     addq.b  #2,routine_secondary(a0)
10.     move.l  #Obj5D_MapUnc_2EEA0,mappings(a0)
11.     move.w  #make_art_tile(ArtTile_ArtNem_EggpodJets_1,0,0),art_tile(a0)
12.  

Change this to:

Code (ASM):

1.  
2. loc_2E9A8:
3.     movea.l Obj5D_parent(a0),a1 ; a1=object
4.     btst    #6,Obj5D_status2(a1)
5.     bne.s   +
6.     rts
7. ; ===========================================================================
8. +
9.     addq.b  #2,routine(a0)
10.     move.l  #Obj5D_MapUnc_2EEA0,mappings(a0)
11.     move.w  #make_art_tile(ArtTile_ArtNem_BossSmoke_1,1,0),art_tile(a0)
12.  

This will fix the spawning of the smoke puff (the change from routine_secondary to routine) and set correct graphics and palette (the other change).

 

Just linking a fix for the Special Stage here to keep all the bugfixes in one place.

 

I'm bringing attention to these set of unused subroutines that can be found within the data of the Nick Arcade and Simon Wai builds; they seem to be converting some set of data for use in-game (similar to ConvertCollisionArray):

Code (Text):

1. ; ===========================================================================
2. ; ---------------------------------------------------------------------------
3. ; Unknown subroutine, presumably converts data for use in-game (which
4. ; would require a dev cart that can write to itself, not normal carts)
5. ; ---------------------------------------------------------------------------
6. ; UnknownSub_1:
7.         lea    ($FFFF0000).l,a1
8.         move.w    #$2EB,d2
9.  
10. loc_3A3A:
11.         move.w    (a1),d0
12.         move.w    d0,d1
13.         andi.w    #$F800,d1
14.         andi.w    #$7FF,d0
15.         lsr.w    #1,d0
16.         or.w    d0,d1
17.         move.w    d1,(a1)+
18.         dbf    d2,loc_3A3A
19.         rts
20. ; ===========================================================================
21. ; UnknownSub_2:
22.         lea    ($FE0000).l,a1
23.         lea    ($FE0080).l,a2
24.         lea    ($FFFF0000).l,a3
25.         move.w    #$3F,d1
26.  
27. loc_3A68:
28.         bsr.w    UnknownSub_4
29.         bsr.w    UnknownSub_4
30.         dbf    d1,loc_3A68
31.         lea    ($FE0000).l,a1
32.         lea    ($FF0000).l,a2
33.         move.w    #$3F,d1
34.  
35. loc_3A84:
36.         move.w    #0,(a2)+
37.         dbf    d1,loc_3A84
38.         move.w    #$3FBF,d1
39.  
40. loc_3A90:
41.         move.w    (a1)+,(a2)+
42.         dbf    d1,loc_3A90
43.         rts
44. ; ===========================================================================
45. ; UnknownSub_3:
46.         lea    ($FE0000).l,a1
47.         lea    ($FFFF0000).l,a3
48.         moveq    #$1F,d0
49.  
50. loc_3AA6:
51.         move.l    (a1)+,(a3)+
52.         dbf    d0,loc_3AA6
53.         moveq    #0,d7
54.         lea    ($FE0000).l,a1
55.         move.w    #$FF,d5
56.  
57. loc_3AB8:
58.         lea    ($FFFF0000).l,a3
59.         move.w    d7,d6
60.  
61. loc_3AC0:
62.         movem.l    a1-a3,-(sp)
63.         move.w    #$3F,d0
64.  
65. loc_3AC8:
66.         cmpm.w    (a1)+,(a3)+
67.         bne.s    loc_3ADE
68.         dbf    d0,loc_3AC8
69.         movem.l    (sp)+,a1-a3
70.         adda.w    #$80,a1
71.         dbf    d5,loc_3AB8
72.         bra.s    loc_3AF8
73. ; ---------------------------------------------------------------------------
74.  
75. loc_3ADE:
76.         movem.l    (sp)+,a1-a3
77.         adda.w    #$80,a3
78.         dbf    d6,loc_3AC0
79.         moveq    #$1F,d0
80.  
81. loc_3AEC:
82.         move.l    (a1)+,(a3)+
83.         dbf    d0,loc_3AEC
84.         addq.l    #1,d7
85.         dbf    d5,loc_3AB8
86.  
87. loc_3AF8:
88.         bra.s    loc_3AF8
89.  
90. ; ||||||||||||||| S U B R O U T I N E |||||||||||||||||||||||||||||||||||||||
91.  
92.  
93. UnknownSub_4:
94.         moveq    #7,d0
95.  
96. loc_3AFC:
97.         move.l    (a3)+,(a1)+
98.         move.l    (a3)+,(a1)+
99.         move.l    (a3)+,(a1)+
100.         move.l    (a3)+,(a1)+
101.         move.l    (a3)+,(a2)+
102.         move.l    (a3)+,(a2)+
103.         move.l    (a3)+,(a2)+
104.         move.l    (a3)+,(a2)+
105.         dbf    d0,loc_3AFC
106.         adda.w    #$80,a1
107.         adda.w    #$80,a2
108.         rts
109. ; End of function UnknownSub_4

EDIT: Actually, the last three subroutines seem to be duplicates of LevelLayout_Convert.

 

Not sure if this one has been noted before, it's easy to miss, but apparently when you break Buzzer, it's exhaust sprite actually lingers on for a little while longer:

 

Haha, good catch! A peek at the disassembly should hopefully explain what's going on there:

Code (ASM):

1. ; loc_2D090:
2. Obj4B_Flame:
3.     movea.l    Obj4B_parent(a0),a1 ; a1=object
4.     tst.b    id(a1)
5.     beq.w    JmpTo49_DeleteObject    ; branch, if object slot is empty. This check is incomplete and very unreliable; check Obj50_Wing to see how it should be done
6.     tst.w    Obj4B_turn_delay(a1)
7.     bmi.s    +        ; branch, if parent isn't currently turning around
8.     rts

You might be wondering what exactly is wrong here: when an object is destroyed, the ID of its now-empty RAM slot is set to 0, so this should be a perfectly-adequate way to detect when the Buzzer object is destroyed and to then delete the flame object. Well, here's what Obj50_Wing does:

Code (ASM):

1.  
2. ; loc_2CDCA:
3. Obj50_Wing:
4.     movea.l    Obj50_parent(a0),a1 ; a1=object
5.     tst.b    id(a1)        ; is parent object's slot empty?
6.     beq.w    JmpTo48_DeleteObject    ; if yes, branch
7.     cmpi.b    #ObjID_Aquis,(a1)    ; is parent object ObjID_Aquis?
8.     bne.w    JmpTo48_DeleteObject    ; if not, branch
9.     btst    #7,status(a1)        ; is parent object marked as destroyed?
10.     bne.w    JmpTo48_DeleteObject    ; if yes, branch
11.     lea    (Ani_obj50).l,a1
12.     jsrto    (AnimateSprite).l, JmpTo14_AnimateSprite
13.     jmpto    (DisplaySprite).l, JmpTo32_DisplaySprite

As this code suggests, it's absolutely possible for a new object to be loaded into the Buzzer's RAM slot right after it is destroyed, before the flame object ever has a chance to check if the slot is empty. The solution to this is instead not to check if the object slot's ID is 0, but rather if it simply isn't the ID of a Buzzer. Of course, in theory, it is technically possible for the Buzzer's RAM slot to be occupied by another Buzzer object, so this check isn't fool-proof, but it mostly works.

I'm pretty sure that the object which gets loaded into the Buzzer's RAM slot is always the points object - notice how both the flame and the points disappear at the same time? (EDIT: I'm dumb: it's the explosion object that gets loaded into the slot, not the points object).

Anyway, this new check makes the previous check redundant, so you can safely remove the stuff for checking if the ID is 0 and the code will work just as well.