Transform at will in Sonic 2

Wow, this is beyond useful. I'm glad you guys finally got this issue addressed. Could you also provide the ROM with this implementation? :v:

 

So much for me knowing anything about asm if this is basic. As far as I'm concerned, I haven't seen this in any hacks of Sonic 2.

 

Just because you have not seen it does not mean it is complex.

 

Should this be put in the guide then?

 

This was one of the first things I did when I hacked Sonic 2. Depending on how you code it, it either completely or partially fixes the "transform after signpost" glitch. My implementation still allowed you to transform if you hit the button exactly as you pass the signpost, leaving you stuck walking in the air as in the original glitch. I was never quite able to pin down a fix for that before I lost interest.

 

Yes, but the glitch that still remains is when you jump past the signpost as regular Sonic and activate the Super transformation, which leaves you stuck walking/running in the air with the results screen not appearing.

 

Lol, I didn't expect that me helping you with that manual transformation thingie yesterday will do a guide.
Anyways, this is quite helpful one, because the way transformation was done in the original Sonic 2 is really annoying. I hope in future we'll see more Sonic 2 hacks with better way of transformation.

But frankly, solution this guide suggests is not perfect, I would say, 'hack-ish'. I mean that Sonic_CancelSuper subroutine I wrote for you. I knew this wasn't all good from the beginning, but hell, for some reason I couldn't think properly yesterday. Silly me. Because the good solution was so simple.

Let me fix my stupid mistake and introduce this good solution as an alternative to your guide:

* * *

Go to Sonic_JumpHeight and replace this:

Code (Text):

1.         tst.b   y_vel(a0)               ; is Sonic exactly at the height of his jump?
2.         beq.s   Sonic_CheckGoSuper      ; if yes, test for turning into Super Sonic
3.         rts

with this:

Code (Text):

1.         move.b  (Ctrl_1_Press_Logical).w,d0
2.         andi.b  #button_B_mask|button_C_mask|button_A_mask,d0 ; is a jump button pressed?
3.         bne.s   Sonic_CheckGoSuper      ; if yes, test for turning into Super Sonic
4.         rts

Goto Sonic_CheckGoSuper and replace:

Code (Text):

1.     bne.s   return_1ABA4

at the very beginning with

Code (Text):

1.     bne.w   Sonic_RevertToNormal

That's it.

* * *

Now, there are few bugs that original game has:
1) Sonic's transformation palette bug
2) Sonic freezing in air after revert to normal bug
They are much easier to fix.

* * *

1) Sonic's transformation palette bug

A palette bug occurs when you transform for the second time and on: Sonic colors look wrong during transformation animation. It happens due to program error in Super palette cycling code. The code resets palette position incorrectly when revert to normal cycle is over.

For HG disassembly.
Goto PalCycle_SuperSonic_revert and find these lines:

Code (Text):

1.     subq.w  #8,(Palette_frame).w    ; previous frame
2.     bcc.s   +           ; branch, if it isn't the first frame
3.     move.b  #0,(Palette_frame).w

The last instruction uses 'byte' type, while the variable used as 'word' in the rest of the code (see SUBQ line for example). Therefore, the variable is not cleared properly, which causes wrong colors to load in the next transformation.
Replace '.b' with '.w' and the bug is gone.

For Xenowhirl's 2007 Disassembly.
The label you're looking for is loc_2188 and those 3 lines look like this:

Code (Text):

1.     subq.w  #8,($FFFFF65C).w
2.     bcc.s   loc_21B0
3.     move.b  #0,($FFFFF65C).w

* * *

2) Sonic freezing in air after revert to normal bug

It happens when Sonic has to revert from transformation instantly. The controls are looked when the transformation starts until a certain moment (controlled by PalCycle_SuperSonic routine), and routine that reverts Sonic to normal doesn't bother to unlock the controls.

In the beginning of Sonic_RevertToNormal add:

Code (Text):

1.     move.b  #0,(MainCharacter+obj_control).w    ; restore Sonic's movement

Applies to both disassemblies.

 

I totally forgot about the transformation palcycle bug, it's something the average player would never encounter in vanilla Sonic 2. I remember posting a quick fix for it years ago, it took me the longest time to track that one down due to its utter simplicity, but I don't know that it ever found its way into any guides.

As for the "stuck in the air" bug, I had never even thought of simply restoring player control in the RevertToNormal routine. It seems like there should be a better way to do it, but I think that more or less cuts it.

 

It's nothing to do with palettes. This is DMA transfer bug, it happens when transferred Sonic's art crosses 128 KB ROM bank.
Check out this post for fixing it: http://forums.sonicretro.org/index.php?showtopic=10880&st=3915&p=626425&#entry626425
This is for Sonic 1. In Sonic 2 it's exactly the same, except for the label you'll be looking for is 'ArtUnc_Sonic'.

 

I use to have that problem years ago, but "align $20000" takes up quite a bit of space. I use "align $10000" (any lower and the glitch still happens) and I haven't had any glitches since. So I've applied this for all my characters. Seeming as I've had no problems since, I guess this is fine?

 

Align $10000 aligns to 64KB, the issue can still happen if the artwork crosses a 128KB boundary. Didn't check how big are Sonic's sprites though, if they're under 64KB then it's never going to cross a 128KB boundary anyways (since they won't cross a 64KB one, and 128KB boundaries are also 64KB boundaries - similar rules apply to other powers of two).

The best way to avoid wasting space is moving stuff around though =P

 

Mine's at 81KB, but still no problems =P


Anyway, that's useful to know, thanks for the tip.

 

Yes, sure. If your art is smaller than $10000 bytes (64 KB), you can align it like that without worrying that your art may cross 128 KB boundary.
But notice, that bug only happens when transferred tiles cross the boundary, not the whole art. So you may even place one bunch of tiles in before the boundary, and another after it, for example. But such alignment would be a real pain in ass though =P

But like Sik said, to avoid wasting space, it's good to organize your data order. Use listing file to see what offsets your data takes and how much 'align' directives take. If they take too much, you can always move some data from end of ROM to wasted space.

 

I generally tend to do that, actually, but I can afford to do it because each sprite is its own file in the source code, so at worst alignment would affect only one sprite and nothing else.