MoDule's bugfix guides Vol. 1

Nice to see these all collected, it should really help the beginners.

I did spot an error in your error correction guides: in the Super Sonic part, on the deceleration bug, you substitute a value that is too low (3) compared to what it is for normal Sonic (6).

 

Hello Sonic CD's Tidal Tempest Zone - the only place where I've noticed it, bugs the living hell out of me.

 

Thanks for posting those. The explanations were a nice read even for those of us who haven't worked much with disassemblies.

Are you going to include any Sonic 3 fixes? I hope somebody can eventually fix those annoying moonjumps when Sonic gets off the underwater rotating cylinders.

 

Nice read MoDule! I have suffered from the low jump out of water many times in my simulator(s), where the water height causes my Knuckles player troubles as his jump height is already low, it is almost impossible to jump out of the water.

I am a little scared of applying any fixes regarding the stand/roll difference change, as changing those causes other things to go crazy. A new way of handling the difference (that 5 pixels offset change on Y pos) was introduced in Sonic 3 to fix the Sonic 2 spindash bug (when spindashing, and aborting the spindash during the charge, either by jumping and releasing direction at the right moment (causing the player to jump straight up in the air), or spindashing directly against a wall), the player get stuck 5 pixels into the ground. This fix must be applied before applying any other fixes regarding that area, or your fixes are not Sonic 3 compatible. In Sonic 3, the SST bytes $44 and $45 holds the original bounding box (I have never seen them change, so I call them original values, however, knowing Sonic 3, they are probably changed at some point from some other object dusing some special moment, BUT ANYHOW they can be hardcoded in Sonic 1 and 2), and when the player is restored from rolling state, look what they do.

+ - Nice to see some bug fixes that are actually bug fixes, and not prefered-by-some-guy fixes (roll jumping enable direction controls because I like it, have no idea game might actually break because of it), nor Sonic-was-supposed-to-do-this-because-I-can-program-asm fixes (jumping with angle forces in S1 special stage), nor fixes-changing-the-original-play-is-not-meant-to-be (spindash rev counter overflow, sure a mistake in the code, but changing that now will mess up the timings of every level designed for the original behaviour). Very sorry you guys who I directly said my opinion against without naming you. MoDule is doing a great job, nailing the real issues of the Sonic player, bringing them up like this.  

 

$44 and $45 are the standing half-height and half-width; I can attest that they are only ever set during player initialization, and are henceforth ever only read from. I know this by two different routes: 1) a couple years ago, I wrote a minor LUA script which I used in Gens rerecording to track changes to SST variables for Sonic and Tails, and proceeded to test all objects with it, trying to find more TAS-worthy bugs; 2) more recently, I went through the S3&K SVN disassembly and checked that these 2 are only written to at initialization or when the memory written to is neither Sonic's/Knuckles' nor Tails'.

As for the rest, do you mean plain S3? Because I tested MoDule's in S3&K and it did not show the behavior you mentioned (with or without the fix).

Hrm. Maybe I should contribute my own fix to the infamous spindash cancel bug when you spindash at the edges of the camera...

 

That is what LOst said, basically; what I was saying is that your fix did not cause any of the issues he feared. There is a benefit to using your fix anyway, though: the character's hitbox will be the correct size when jumping from rolling, instead of suddenly increasing to standing hitbox.

 

I love you.

Can those be applied to Sonic 1, though (except the roll jump one, as Sonic 1 doesn't use this standing height thing)? Or these glitches are present only on S2? Just wondering.

 

MoDule: do you mind if I add another Super Sonic bug fix to your collection? There is one more bug related to end-of-level transformation that still happens even with the S3&K fix. This bug requires more bad luck than anything, but it does happen: if you trigger the transformation on the very same frame when the timer is stopped by the signpost, Sonic will begin transforming and get stuck on air again. This happens because Sonic's object code runs before the collision with the signpost is checked; thus, the transformation will begin and then be halted when the signpost code runs and stops the timer. But since the transformation never ends, the object control flags are still set and Sonic still gets stuck on air.

If you are wondering: the same issue happens in S3&K if you trigger the transformation at the very same frame when Tails hits the boss (either act) the final time. It is even rarer, but it has happened.

 

After looking a bit more into it, I see that the bug I mentioned is S3&K-specific -- it is not possible to trigger it in S2 unless you have a hack that either enables Tails to end the level or enables multiple characters to trigger the transformation, in which case you will need special code to prevent graphical glitches. I will make an entry at the S3&K section about the bug.

In any case, the fix for the screen boundary spindash bug is done.

 

The fix I have for that Super Sonic problem is this: find Sonic_RevertToNormal and modify the code so that this:

Code (ASM):

1. Sonic_RevertToNormal:
2.     move.b  #2,(Super_Sonic_palette).w  ; Remove rotating palette
3.     move.w  #$28,(Palette_frame).w
4.     move.b  #0,(Super_Sonic_flag).w
5.     move.b  #1,next_anim(a0)    ; Change animation back to normal ?
6.  

becomes this:

Code (ASM):

1. Sonic_RevertToNormal:
2.     tst.b   (Super_Sonic_palette).w     ; Are we interrupting a transformation to Super Sonic?
3.     bmi.s   +               ; branch if not
4.     move.b  #0,obj_control(a0)      ; restore Sonic's movement if yes
5.     bra.s   ++              ; Do not change current palette index, which will be less than $28
6. +
7.     move.w  #$28,(Palette_frame).w      ; Fade out from Super Sonic palette
8. +
9.     move.b  #2,(Super_Sonic_palette).w  ; Remove rotating palette
10.     move.b  #0,(Super_Sonic_flag).w
11.  

This restores normal movement from an unfinished transformation (Super_Sonic_palette >= 0 means the transformation hasn't finished). It changes the code to also fade out from super palette only if it is needed: it fades from current palette index instead of flashing to full super palette before fading. This works because Palette_frame is less than $28 if Super_Sonic_palette >= 0. The next_anim line can be (and was) removed without any ill effects; all it does is reset the animation (except for the running animation, which is not reset).

"next_anim" is a misnomer, by the way; "prev_anim" or "last_anim" are better names: if you look at Sonic_Animate, you will see that if anim(a0) != next_anim(a0), then next_anim(a0) is set to anim(a0) and the animation is reset. This clearly is not the behavior you expect from the name.

 

Is there any Hivebrain disassembler's version of these guides? They are greatly useful, but I'm not using the SVN source and I'm too lazy for convert the values.

 

I'm obligated to post this again, no matter how annoying it's probably getting.