[Sik]

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

[redhotsonic]

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


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

[vladikcomper]

redhotsonic, on 28 May 2012 - 12:36 PM, said:

vladikcomper, on 28 May 2012 - 10:56 AM, said:

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.sonicr...25
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?

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.

[Sik]

vladikcomper, on 28 May 2012 - 02:45 PM, said:

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

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.

[Machenstein]

I found a small quirk with vladikcomper's alternative to the guide. If you push the transform button when don't have all 7 Chaos Emeralds and 50 rings, Sonic simply flashes yellow for a second. I would suggest going with the subroutine in the first guide until this issue is fixed with the alternative one.

[vladikcomper]

Machenstein, on 29 May 2012 - 04:58 PM, said:

I found a small quirk with vladikcomper's alternative to the guide. If you push the transform button when don't have all 7 Chaos Emeralds and 50 rings, Sonic simply flashes yellow for a second. I would suggest going with the subroutine in the first guide until this issue is fixed with the alternative one.

I just tested my code again and there is no such bug.

Maybe you forgot to delete some code from the first guide before applying my alternative one? Check if you don't have anything odd in Sonic_CheckGoSuper as well. Because it looks like something calls Sonic_RevertToNormal where it isn't needed.

[flamewing]

Knucklez, on 27 May 2012 - 10:13 PM, said:

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.

It is basic; and try my hack for an example.

[Knucklez]

flamewing, on 30 May 2012 - 08:13 AM, said:

Knucklez, on 27 May 2012 - 10:13 PM, said:

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.

It is basic; and try my hack for an example.

Oh yeah, I forgot about that, but you did a lot more than basic coding when it came to how your Super forms functioned (I'm assuming).

[Machenstein]

vladikcomper, on 30 May 2012 - 02:51 AM, said:

Machenstein, on 29 May 2012 - 04:58 PM, said:

I found a small quirk with vladikcomper's alternative to the guide. If you push the transform button when don't have all 7 Chaos Emeralds and 50 rings, Sonic simply flashes yellow for a second. I would suggest going with the subroutine in the first guide until this issue is fixed with the alternative one.

I just tested my code again and there is no such bug.

Maybe you forgot to delete some code from the first guide before applying my alternative one? Check if you don't have anything odd in Sonic_CheckGoSuper as well. Because it looks like something calls Sonic_RevertToNormal where it isn't needed.

I think the problem was this part threw me off:

Quote

Goto Sonic_CheckGoSuper and replace:

	bne.s	return_1ABA4

with

	bne.w	Sonic_RevertToNormal

Because there are two "bne.s return_1ABA4" under Sonic_CheckGoSuper, so I replaced both of them with Sonic_RevertToNormal. Should I only replace the first one?

This post has been edited by Machenstein: 30 May 2012 - 10:13 AM

[vladikcomper]

Machenstein, on 30 May 2012 - 10:12 AM, said:

Because there are two "bne.s return_1ABA4" under Sonic_CheckGoSuper, so I replaced both of them with Sonic_RevertToNormal. Should I only replace the first one?

Yes. I meant to replace only the first one.
I wrote the guide quickly and I didn't take into account that someone would want to replace the second one, that goes after 'cmpi.b #7,(Emerald_count).w' line. In terms of basic program logic, it will be incorrect and cause the bug you've got. The logic will be: 'Does Sonic has 7 emeralds? If not, goto Sonic_RevertToNormal'. You know what it causes already: Sonic flashes yellow (reverts to normal) when he is in normal form.

EDIT: Just edited the guide to mention that. I think it doesn't have any ambiguous places now.

This post has been edited by vladikcomper: 30 May 2012 - 03:22 PM

[KingofHarts]

I really think this belongs on the SCHG. If someone can put together a final guide with no problems, I can slap it onto a wiki page for you guys.

[Machenstein]

There is actually one major problem with the code that I haven't brought up here. If you have more than 50 rings at the end of Wing Fortress Zone, Sonic will transform and revert multiple times when he jumps for the Tornado and fall to his death. I'm sure it has something to do with this subroutine.

ObjB2_Prepare_to_jump:
	bsr.w	ObjB2_Waiting_animation
	addq.w	#1,objoff_2A(a0)
	cmpi.w	#$30,objoff_2A(a0)
	bne.s	+
	addq.b	#2,routine_secondary(a0)
	move.w	#(button_A_mask<<8)|button_A_mask,(Ctrl_1_Logical).w
	move.w	#$38,objoff_2E(a0)
	tst.b	(Super_Sonic_flag).w
	beq.s	+
	move.w	#$28,objoff_2E(a0)
+
	bsr.w	ObjB2_Align_plane
	bra.w	JmpTo45_DisplaySprite
; ===========================================================================

ObjB2_Jump_to_plane:
	clr.w	(Ctrl_1_Logical).w
	addq.w	#1,objoff_2A(a0)
	subq.w	#1,objoff_2E(a0)
	bmi.s	+
	move.w	#((button_right_mask|button_A_mask)<<8)|button_right_mask|button_A_mask,(Ctrl_1_Logical).w
	[...]

A quick way to fix this is to change all instances of "button_A_mask" with whatever is not your transformation button. But for those who have all three buttons as their transformation button, I don't have an answer there. Perhaps someone more knowledgeable could provide a better solution.

[Aerosol]

Why not "turn off" all of your emeralds in the code before it makes sonic jump, and turn them back on before the subroutine ends?

[dsrb]

Yeah, there must be some way to, before/after cutscenes, set/unset a flag that will prevent transformation. Changing the button required/recognised is a horribly kludgy way to do it.

[MoDule]

It's a bit roundabout, but you could try stopping the timer at the beginning of the chase sequence after applying the first fix from my guide: SCHG_How-to:Fix_bugs_relating_to_Super_Sonic