MoDule's bugfix guides Vol. 1

I don't know what you mean. I see the bug both in S3 and S3&K. The camera is always a few pixels too high when Tails rolls. I even checked the vertical scroll routine and it makes the same mistake as S2.

I know. That happened when I moved the guides from my personal space to the guides section and screwed up the first time. Now they're stuck with those weird titles and I don't know how to fix it.

You raise a good point. I'll do that right away.

 

It's not so much during the roll as in the transition from walking to rolling. I just tested it with debug mode in CNZ act 1 (Carnival Night Zone, S3&K), looking at the camera positions. For walking it gives me a y position of $670 and for rolling a position of $66C. It's also pretty noticeable if you look at the bottom of the screen. This is with Tails; it doesn't happen for the other two.

 

I'm curious, what was wrong with the original one? The new version is quite different.

So I finally got around to writing another guide. This time it's about a known bug in OOZ (you know, the fun one which lets you go really fast).

How-to:Fix the OOZ launcher speed up glitch

I also updated the Tails roll camera guide. The original fix only worked if the player was on the ground. There's a similar bug when a player rolls while going up/down a wall, but I haven't been able to come up with a satisfactory fix for this yet.

Lastly, I added my version for that other Super Sonic bug. If you want to add yours as an alternative, feel free to do so.

Just for fun, here's a list of text files to show what else I'm working on (slowly):

• Fix the Rexxon crash bug.txt
• Retain speed on slope after getting hit.txt
• Give characters individual chain bonus counters.txt
• Fix CPZ spin tube bug.txt
• Fix bug in pinball mode object.txt

They're all empty right now and there's a few for which I haven't even made a file yet, but I'm sure you get the idea.

 

Possible, probably, easy, no. The simplest one I can think of is the roll jump height fix, since all you'd have to do there is replace the offending instructions with NOPs, or ones where you just have to change a number or branch type.

Ah yes, that makes sense.

Now I just have to write them...

 

Since it's been a while, I thought I'd post a new little bug fix I just finished. No wiki this time, sorry. If someone would be kind enough to volunteer to wiki this, I'd be very thankful. Otherwise, I'd just take care of it myself, (whe)never.
What I've got this time is a bug I've actually already posted partial fixes for in the past and even made a slightly better fix recently. Pretty much out of the blue, a much more elegant solution came to me just a few minutes ago.

The bug: The player object's speed values behave inconsistently when entering and exiting water. For instance, if a player falls into water while speed shoes are active, the sped up movement stats will be lost; should the power up run out under water, then the player will receive above water normal stats. This bug exists in all of the four main series games.

The fix (s2 semi recent hg disassembly):
First, locate Obj01_InWater and comment out or remove a few lines as follows:

Code (ASM):

1.     (...)
2. ;   move.w  #$300,(Sonic_top_speed).w
3. ;   move.w  #6,(Sonic_acceleration).w
4. ;   move.w  #$40,(Sonic_deceleration).w
5. ;   tst.b   (Super_Sonic_flag).w
6. ;   beq.s   +
7. ;   move.w  #$500,(Sonic_top_speed).w
8. ;   move.w  #$18,(Sonic_acceleration).w
9. ;   move.w  #$80,(Sonic_deceleration).w
10. ;+
11.     (...)

Do the same for Obj01_OutWater:

Code (ASM):

1.     (...)
2. ;   move.w  #$600,(Sonic_top_speed).w
3. ;   move.w  #$C,(Sonic_acceleration).w
4. ;   move.w  #$80,(Sonic_deceleration).w
5. ;   tst.b   (Super_Sonic_flag).w
6. ;   beq.s   +
7. ;   move.w  #$A00,(Sonic_top_speed).w
8. ;   move.w  #$30,(Sonic_acceleration).w
9. ;   move.w  #$100,(Sonic_deceleration).w
10. ;+
11.     (...)

It might seem odd to simply remove these lines, as they are what make the players slower/faster under/above water, but the next set of changes should make the solution clear:
Locate Sonic_Move, which should look like this:

Code (ASM):

1. Sonic_Move:
2.     move.w  (Sonic_top_speed).w,d6
3.     move.w  (Sonic_acceleration).w,d5
4.     move.w  (Sonic_deceleration).w,d4
5.     (...)

Underneath the last displayed line, add this:

Code (ASM):

1.     btst    #6,status(a0)   ; is Sonic under water?
2.     beq.s   +       ; if not, branch
3.     lsr.w   #1,d4   ; reduce stats
4.     lsr.w   #1,d5
5.     lsr.w   #1,d6
6. +

Next, do the same for Sonic_RollSpeed:

Code (ASM):

1.     move.w  (Sonic_top_speed).w,d6
2.     asl.w   #1,d6
3.     move.w  (Sonic_acceleration).w,d5
4.     asr.w   #1,d5   ; natural roll deceleration = 1/2 normal acceleration
5.     move.w  #$20,d4 ; controlled roll deceleration... interestingly,
6.             ; this should be Sonic_deceleration/4 according to Tails_RollSpeed,
7.             ; which means Sonic is much better than Tails at slowing down his rolling when he's underwater
8.     btst    #6,status(a0)   ; is Sonic under water?
9.     beq.s   +       ; if not, branch
10.     lsr.w   #1,d5   ; reduce stats
11.     lsr.w   #1,d6
12. +

and Sonic_ChgJumpDir:

Code (ASM):

1.     move.w  (Sonic_top_speed).w,d6
2.     move.w  (Sonic_acceleration).w,d5
3.     asl.w   #1,d5
4.     btst    #6,status(a0)   ; is Sonic under water?
5.     beq.s   +       ; if not, branch
6.     lsr.w   #1,d5   ; reduce stats
7.     lsr.w   #1,d6
8. +

Finally, in Sonic_RevertToNormal remove the following lines:

Code (ASM):

1.     (...)
2. ;   btst    #6,status(a0)   ; Check if underwater, return if not
3. ;   beq.s   return_1AC3C
4. ;   move.w  #$300,(Sonic_top_speed).w
5. ;   move.w  #6,(Sonic_acceleration).w
6. ;   move.w  #$40,(Sonic_deceleration).w

Of course, these same changes need to be applied to the other player objects where applicable.
In S3&K, the speed stats are not read or written to directly by the player objects. Instead, the address of the first value is loaded into a4 and the RAM addresses are accessed as follows:

Code (ASM):

1.     move.w  #$600,(a4)  ; top speed
2.     move.w  #$C,2(a4)   ; acceleration
3.     move.w  #$80,4(a4)  ; deceleration

If this fix is applied, the Wrong speed when transforming under water part of the Super Sonic fixes no longer needs to, or rather, should not be applied.

An explanation: The original problem comes from the fact that there are so many cases to consider when assigning the correct speed values with and without speed shoes and when super. Most of the cases were simply left out. Our fix simply circumvents the problem by calculating the correct under water stats when necessary.

Incidentally, this only works if you wish to preserve the original under water physics, namely making everything half as fast. If for whatever reason someone wants to use a custom set of speed values under water, I will gladly post my previous fix as well.

 

Bit of a big bump, sorry, but I just noticed there's a bug in one of my bug-fixes. The one about the ARZ boss's pillars, to be more precise: this one.
I forgot to clear the pillar object's standing and pushing bits, which would result in characters sliding along the ground, because they'd be put into an in-air state every frame until the pillars are gone. Anyway, that's fixed now.

I'll try and see if I can come up with some new things soon.

 

Speaking of the water fix, I think I might have left out a few edge cases in the original fix. I'll post that one tomorrow.

I think someone's already fixed the first one, not sure, though. Never even seen the second one. I'll try giving it a look, can't make any guarantees.

Edit: OK, here's a short writeup on what I changed in my water fix. Let me know if this makes sense. For reference, here's the original guide.
To begin with, let's look at the code in vanilla Sonic 2:

Code (ASM):

1. ; loc_1A18E:
2. Obj01_InWater:
3.     move.w  (Water_Level_1).w,d0
4.     cmp.w   y_pos(a0),d0    ; is Sonic above the water?
5.     bge.s   Obj01_OutWater  ; if yes, branch
6.  
7.     ; <-- (1)
8.  
9.     bset    #6,status(a0)   ; set underwater flag
10.     bne.s   return_1A18C    ; if already underwater, branch
11.  
12.     movea.l a0,a1
13.     bsr.w   ResumeMusic
14.     move.b  #ObjID_SmallBubbles,(Sonic_BreathingBubbles+id).w ; load Obj0A (sonic's breathing bubbles) at $FFFFD080
15.     move.b  #$81,(Sonic_BreathingBubbles+subtype).w
16.     move.l  a0,(Sonic_BreathingBubbles+$3C).w
17.     move.w  #$300,(Sonic_top_speed).w
18.     move.w  #6,(Sonic_acceleration).w
19.     move.w  #$40,(Sonic_deceleration).w
20.     tst.b   (Super_Sonic_flag).w
21.     beq.s   +
22.     move.w  #$500,(Sonic_top_speed).w
23.     move.w  #$18,(Sonic_acceleration).w
24.     move.w  #$80,(Sonic_deceleration).w
25. +
26.     asr.w   x_vel(a0)
27.     asr.w   y_vel(a0)   ; memory operands can only be shifted one bit at a time
28.  
29.     ; <-- (3)
30.  
31.     asr.w   y_vel(a0)
32.     beq.s   return_1A18C
33.     move.w  #$100,(Sonic_Dust+anim).w   ; splash animation
34.     move.w  #SndID_Splash,d0    ; splash sound
35.     jmp (PlaySound).l

What I did in the original guide was to place a check if Sonic is moving upward while entering water at (1) to prevent his y_vel from being lowered. This was so jumping while close to the water surface doesn't unexpectedly lower your jump height. I figured, it's probably better to have such a check for exiting water, as well, even if I can't think of a scenario in which you'd move above the water while falling. So here it is:
In the following code:

Code (ASM):

1. ; loc_1A1FE:
2. Obj01_OutWater:
3.     bclr    #6,status(a0) ; unset underwater flag
4.     beq.s   return_1A18C ; if already above water, branch
5.  
6.     movea.l a0,a1
7.     bsr.w   ResumeMusic
8.     move.w  #$600,(Sonic_top_speed).w
9.     move.w  #$C,(Sonic_acceleration).w
10.     move.w  #$80,(Sonic_deceleration).w
11.     tst.b   (Super_Sonic_flag).w
12.     beq.s   +
13.     move.w  #$A00,(Sonic_top_speed).w
14.     move.w  #$30,(Sonic_acceleration).w
15.     move.w  #$100,(Sonic_deceleration).w
16. +
17.     cmpi.b  #4,routine(a0)  ; is Sonic falling back from getting hurt?
18.     beq.s   +       ; if yes, branch
19.  
20.     ; <-- (2)
21.  
22.     asl y_vel(a0)
23. +
24.     tst.w   y_vel(a0)
25.     beq.w   return_1A18C
26.     move.w  #$100,(Sonic_Dust+anim).w   ; splash animation
27.     movea.l a0,a1
28.     bsr.w   ResumeMusic
29.     cmpi.w  #-$1000,y_vel(a0)
30.     bgt.s   +
31.     move.w  #-$1000,y_vel(a0)   ; limit upward y velocity exiting the water
32. +
33.     move.w  #SndID_Splash,d0    ; splash sound
34.     jmp (PlaySound).l
35. ; End of subroutine Sonic_Water

add this:

Code (ASM):

1.     tst.w   y_vel(a0)   ; is Sonic moving downward?
2.     bpl.w   return_1A18C    ; if yes, don't boost his speed

at the location indicated by (2). Of course, this also needs to be done for Tails and any other characters other than Sonic.
Another thing I experimented with, was to move the check at (1) to the location at (3). This sort of still allows the bug to happen, but it only divides Sonic's y_vel by 2, avoiding the original problem. I'm not sure which one I like better, though.

 

Double post, so
After tinkering with this a little more, I think I've found something satisfying.
So now my routines look like this:

Code (ASM):

1. ; loc_1A18E:
2. Obj01_InWater:
3.     move.w  (Water_Level_1).w,d0
4.     cmp.w   y_pos(a0),d0    ; is Sonic above the water?
5.     bge.s   Obj01_OutWater  ; if yes, branch
6.  
7.     bset    #6,status(a0)   ; set underwater flag
8.     bne.s   return_1A18C    ; if already underwater, branch
9.  
10.     movea.l a0,a1
11.     bsr.w   ResumeMusic
12.     move.b  #ObjID_SmallBubbles,(Sonic_BreathingBubbles+id).w ; load Obj0A (sonic's breathing bubbles) at $FFFFD080
13.     move.b  #$81,(Sonic_BreathingBubbles+subtype).w
14.     move.l  a0,(Sonic_BreathingBubbles+$3C).w
15.     move.w  #$300,(Sonic_top_speed).w
16.     move.w  #6,(Sonic_acceleration).w
17.     move.w  #$40,(Sonic_deceleration).w
18.     tst.b   (Super_Sonic_flag).w
19.     beq.s   +
20.     move.w  #$500,(Sonic_top_speed).w
21.     move.w  #$18,(Sonic_acceleration).w
22.     move.w  #$80,(Sonic_deceleration).w
23. +
24. ;   asr.w   x_vel(a0)
25. ;   asr.w   y_vel(a0)   ; memory operands can only be shifted one bit at a time
26. ;   asr.w   y_vel(a0)
27. ;-- new stuff starts here
28.     asr.w   y_vel(a0)   ; reduce Sonic's falling speed
29.     bmi.s   return_1A18C    ; if Sonic is moving upward (I.e. from jumping), don't slow him down
30.     asr.w   x_vel(a0)   ; else, slow him down...
31.     asr.w   y_vel(a0)   ; ... and reduce his falling speed more
32. ;-- new stuff ends here
33.     beq.s   return_1A18C
34.     move.w  #$100,(Sonic_Dust+anim).w   ; splash animation
35.     move.w  #SndID_Splash,d0    ; splash sound
36.     jmp (PlaySound).l

Here, I replaced the commented out block with the four lines underneath.
In the other routine, I just moved the check up a few lines:

Code (ASM):

1. ; loc_1A1FE:
2. Obj01_OutWater:
3.     bclr    #6,status(a0) ; unset underwater flag
4.     beq.s   return_1A18C ; if already above water, branch
5.  
6.     movea.l a0,a1
7.     bsr.w   ResumeMusic
8.     move.w  #$600,(Sonic_top_speed).w
9.     move.w  #$C,(Sonic_acceleration).w
10.     move.w  #$80,(Sonic_deceleration).w
11.     tst.b   (Super_Sonic_flag).w
12.     beq.s   +
13.     move.w  #$A00,(Sonic_top_speed).w
14.     move.w  #$30,(Sonic_acceleration).w
15.     move.w  #$100,(Sonic_deceleration).w
16. +
17.     ; <-- here
18.     tst.w   y_vel(a0)       ; is Sonic moving downward?
19.     bpl.w   return_1A18C    ; if yes, don't boost his speed
20.  
21.     cmpi.b  #4,routine(a0)  ; is Sonic falling back from getting hurt?
22.     beq.s   +       ; if yes, branch
23.     asl y_vel(a0)
24. +
25.     tst.w   y_vel(a0)
26.     beq.w   return_1A18C
27.     move.w  #$100,(Sonic_Dust+anim).w   ; splash animation
28.     movea.l a0,a1
29.     bsr.w   ResumeMusic
30.     cmpi.w  #-$1000,y_vel(a0)
31.     bgt.s   +
32.     move.w  #-$1000,y_vel(a0)   ; limit upward y velocity exiting the water
33. +
34.     move.w  #SndID_Splash,d0    ; splash sound
35.     jmp (PlaySound).l
36. ; End of subroutine Sonic_Water

I'm probably over-thinking this...

Edit: Just noticed a small bug in my edited InWater routine. I was shifting x_vel(a0) and y_vel(a0) in the wrong order, which caused the branch to return_1A18C to be true when the x_vel is 0, even though it should have been the y_vel. Anyway, I've fixed it in the code block above.