[KingofHarts]

MarkeyJester, on 22 October 2012 - 11:44 PM, said:

Adding/subtracting an immediate word value takes 8 cycles. e.g.:

		addi.w	#$0060,d0

		addi.w	#$0080,d0

Moving a word/quick value to a register first takes 4 cycles, while adding/subtracting the register to another takes a further 4 cycles, totalling 8 cycles. e.g.:

		moveq	#$60,d1		add.w	d1,d0

		moveq	#$FFFFFF80,d1		sub.w	d1,d0

No processing time is saved in this instance, if however, you intend to use the same value more than once in a similar fashion, then it would be recommended to use the register storage method.

Then I'll opt against using a register for this one... since that value is only used once.
Thanks for the tip Markey!

[MarkeyJester]

Bump, PsychoRFG brought something to my attention which I never noticed before, it seems that if you pause while the music is fading in, and then unpause, the DAC does not resume once the music has fully faded in. After a quick look, it seems that the pause routine not only sets the keys off, but it also turns off the left and right speaker panning for each channel (which makes sense due to the release rate), and unpausing causes the system to reset all of the channel's panning/AMS/FMS values, of course, if the music is going through a fade in, then the DAC channel (a.k.a. FM 6) must remain mute until the music has fully faded, hence, the panning/AMS/FMS value for FM 6 does not get updated while DAC is running, until of course either a new track is played, or the game is paused and unpaused again after fading, or the DAC channel changes speakers during its script.

To fix, we need to go to "loc_726D6:"

		bclr	#2,$40(a6)
		clr.b	$24(a6)
		rts

The first instruction clears the fade out mute bit, which was set by the "E4" flag (fade out into previous track), the second instruction clears the fading out flag (telling the system that fading out is complete), the "key on" values are resumed by the system already through natural course, all that's left is to reset the L/R/AMS/FMS of FM6 on the YM2612, like so:

loc_726D6:
		bclr	#2,$40(a6)
		clr.b	$24(a6)
		tst.b	$40(a6)					; is the DAC channel running?
		bpl.s	Resume_NoDAC				; if not, branch
		moveq	#$FFFFFFB6,d0				; prepare FM channel 3/6 L/R/AMS/FMS address
		move.b	$4A(a6),d1				; load DAC channel's L/R/AMS/FMS value
		jsr	sub_72764(pc)				; write to FM 6

Resume_NoDAC:
		rts

What it does should be obvious, but that's about it, my apologies if this has been solved somewhere else before, I didn't see it in the thread or on the wiki.

[KingofHarts]

Wanted to point out two small bugs... god its been a little while since anyone's done this... not since that big bug-busting boom of last year died down in the fall...
ANYWAY First can be found at this link: http://sonicresearch...?showtopic=3422
Not my bug OR fix, but I saw it and will link to it here.

SECOND and this one IS one that I noticed and am reporting... There is a SMALL bug with the horizontal springs. If you run or spin into a horizontal spring facing away from it (which is not that likely to happen, though it does happen at times), Sonic will face towards the spring instead of away from it like he is supposed to. This is because when Sonic hits the horizontal spring, bit 0 (Facing direction) of his status variable is changed from 0 to 1, or vice versa. You can see the code here.

	Spring_Flipped:
		move.w	#$F,move_lock(a1)
		move.w	x_vel(a1),inertia(a1)
		bchg	#0,status(a1) ; <----- There's the culprit!
		btst	#2,status(a1)
		bne.s	loc_DC56
		move.b	#id_Walk,anim(a1) ; use running animation

Here is my proposed fix. If there is a more efficient way of handling this please teach me.

Spring_BounceLR:
		addq.b	#2,routine(a0)
		move.w	spring_pow(a0),x_vel(a1) ; move Sonic to the left
		addq.w	#8,x_pos(a1)
		btst	#0,status(a0)	; is object flipped?
		bne.s	Spring_Flipped	; if yes, branch
		subi.w	#$10,x_pos(a1)
		neg.w	x_vel(a1)	; move Sonic to	the right
	Spring_Flipped:
		move.w	#$F,move_lock(a1)
		move.w	x_vel(a1),inertia(a1)
		; KingofHarts spring direction fix
                cmp.w   #0,x_vel(a1)
		bmi.s   Face_Left    ; if Sonic is running left, branch
                bclr    #0,status(a1)
                bra.s   Face_cont
                ;bchg	#0,status(a1) ; Removed this (KingofHarts spring direction fix)
        Face_Left:
                bset    #0,status(a1)
        Face_Cont: ; End of fix
		btst	#2,status(a1)
		bne.s	loc_DC56
		move.b	#id_Walk,anim(a1) ; use running animation

Basically, my fix has the code set or clear the status bit, based on the sign of x speed, rather than simply flip-flopping it. This allows for Sonic to ALWAYS face the correct direction. Haven't bothered to see if the bug occurs in Sonic 2 or 3K yet BTW. and AGAIN, please let me know if there is a better way to do this.

This post has been edited by KingofHarts: 05 February 2013 - 01:22 PM

[KingofHarts]

Noticed a small omission with the following fix: The walk-jump set of animation fixes

Spoiler

Adding the following 2 lines as noted will prevent Sonic dying in the walking animation (likely due to crushing):

Solid_Ignore:
		btst	#staPush,status(a0)	; is Sonic pushing?
		beq.s	Solid_Debug		; if not, branch
		; Walking animation fixes (REV C Edit)
                cmp.b	#id_Roll,anim(a1)	; check if in jumping/rolling animation
		beq.s	Solid_NotPushing
		cmp.b	#id_Drown,anim(a1)	; check if in drowning animation
		beq.s	Solid_NotPushing
		cmp.b	#id_Hurt,anim(a1)	; check if in hurt animation
		beq.s	Solid_NotPushing
		cmp.b	#id_Death,anim(a1)	; check if in death animation <--- NEW KoH addition
		beq.s	Solid_NotPushing ;<--- NEW KoH addition

Also add those two lines to the Monitor code (follow the guide I linked to, to know where to place these 2 new lines)

Disregard this note I made above. Taking a note from ReadySonic, there is a much quicker and easier way to do this, than the complicated mess that currently sits in the SCHG.

Remove these lines in _incObj\sub SolidObject.asm, Solid_Ignore...

btst	#5,obStatus(a0)	; is Sonic pushing?
beq.s	Solid_Debug	; if not, branch
;move.w	#id_Run,obAnim(a1) ; use running animation REMOVE THIS LINE

... _incObj\26 Monitor.asm, loc_A25C...

btst	#5,obStatus(a0)
beq.s	Mon_Animate
;move.w	#1,obAnim(a1) REMOVE THIS LINE

...and sonic.asm, loc_8AA8...

btst	#5,obStatus(a0)
beq.s	locret_8AC2
;move.w	#id_Run,obAnim(a1) REMOVE THIS LINE

Afterwards, simply need to fix one more thing, and that is the pushing while walking bug.

If Sonic rolls or moves too fast into a wall or solid object and then quickly turns around, he'll often move away from it while using his "push" animation instead of the proper "walk" animation.

The Solution: Sonic 2 solves this by clearing Sonic's "pushing" status bit whenever his animation is supposed to reset.

In _incObj\Sonic Animate.asm, Sonic_Animate: you'll find this code. Add the noted line:

move.b d0,obNextAni(a0) ; set to "no restart"
move.b	#0,obAniFrame(a0) ; reset animation
move.b	#0,obTimeFrame(a0) ; reset frame duration
bclr	#5,obStatus(a0)	; clear pushing flag ; ADD THIS LINE
@do:

NOTE: Please excuse any <div>'s... AND credit to Mercury's ReadySonic for this fix

This post has been edited by KingofHarts: 04 May 2013 - 08:31 AM

[KingofHarts]

Bump for a new fix to an old bug.

The S-tunnel bug in GHZ 1. Go too fast and it kills you. Why? Because... the bottom boundary collision routine is checking the current boundary instead of the intended one... Well, that fixes that...
BUT WAIT, we've caused another new, and unnecessary problem!
We've got to move around a bunch of DLE's because Sonic is instantly dying in midair for no reason. (Also happens in Sonic 3.) WHY? Because the intended lower boundary got moved up... and THAT's the one that is being checked... that's just not right either...

My solution:

@chkbottom: ; Recoded to suit my own preference. Allow Sonic to outrun camera, ALSO prevent sudden deaths. (REV C Edit)
		move.w	(v_limitbtm2).w,d0 ; current bottom boundary=d0
                cmp.w   (v_limitbtm1).w,d0 ; is the intended bottom boundary lower than the current one?
                bcc.s   @notlower          ; if not, branch
                move.w  (v_limitbtm1).w,d0 ; intended bottom boundary=d0
        @notlower:
		addi.w	#$E0,d0
		cmp.w	y_pos(a0),d0	; has Sonic touched the	bottom boundary?
		blt.s	@bottom		; if yes, branch
		rts

Now it only checks the intended bottom boundary if the boundary is moving down... allowing for Sonic to outrun the camera with no issues... If the boundary is moving up, or just not moving, then it acts as it originally intended, aka no more dying in midair.

IMHO THIS should be the bottom boundary routine for all 3 games. Lemme know what you think.

[Tiddles]

Seems reasonable enough, in theory at least, but where in Sonic 3 does this cause an issue?

[KingofHarts]

One instance of going past the rocks in AIZ 1 into Knuckles path... now to be fair, it is up to the user to fix the DLE's so that doesn't happen, if you wanna have Sonic be able to go down there...

BUT if it's gonna kill me, I wanna see it coming, and not have the shit scared outta me. (For some reason, dying unexpectedly in a Sonic game scares me. It's something that has scarred me for life since I was a tot.)

I just think this is a better route to take, especially for players that like to go into debug and mess about or wander around. Like I said, it's my own preference, maybe people won't feel it is necessary.

[flarn2006]

Just wondering, why would you want to prevent players from padding their score by dying? If I considered that to be cheating, I'd just not do it, not find/make a ROM that doesn't allow it.

[KingofHarts]

It's really more for how to do it if one wanted to... as I pointed out back in this thread. If one has a hack that would maybe mandate such a thing, such as Endri's hack, for instance, you might want something like this...

For vanilla Sonic 1, I agree... it's not necessary. Those posts were really more a result of me experimenting and toying around, trying to learn... than anything to be taken seriously for vanilla Sonic 1 use.
That said, its there for anyone to try if they want.

[TheInvisibleSun]

I don't know if this belongs here, but it is possible to jump off to your death in Final Zone after defeating the boss (if you jump at the right moment before the game locks your movement). Though I believe this is known already, what would be the best way to go about correcting this? Personally, I 'fixed' it in my hack by just making the bottom boundary in Final Zone send you to the ending:

@bottom:
		cmpi.w	#(id_SBZ<<8)+2,(v_zone).w ; is level FZ ?
		beq.s	@next
		cmpi.w	#(id_SBZ<<8)+1,(v_zone).w ; is level SBZ2 ?
		bne.w	@killsonic	; if not, kill Sonic
		cmpi.w	#$2000,(v_player+obX).w
		bcs.w	@killsonic
		clr.b	(v_lastlamp).w	; clear	lamppost counter
		move.w	#1,(f_restart).w ; restart the level
		move.w	#(id_LZ<<8)+3,(v_zone).w ; set level to SBZ3 (LZ4)
		rts	
	@next:
		move.b	#id_Ending,(v_gamemode).w
		rts

But what would be the 'ideal' way of fixing this problem?

This post has been edited by TheInvisibleSun: 01 July 2013 - 10:42 AM

[StephenUK]

I'd probably say locking the controls from the moment the final hit has landed and playing out that entire section with pre-recorded movement would be the best way of doing it. An instant control lock would also prevent people from being able to overfow the boss hit counter back to 255.

[Rika Chou]

Then you couldn't get that last hit. I would just put an invisible wall.

[Mercury]

Rika Chou, on 01 July 2013 - 07:34 PM, said:

Then you couldn't get that last hit. I would just put an invisible wall.

This is what I did in ReadySonic.

[KingofHarts]

I did THIS... for Sonic 1. Wasn't all that hard, more time consuming than anything else, what with all of the separated .asm's and all. (One of the few drawbacks to this layout)

Follow these steps to do the same:

1. GET A FREE UNIVERSAL SST - You can do this a couple of ways... I chose to do this. (Based on RHS' SST guide)
obActWid: Switch from $19 to $14.
obPriority: Switch from $24 to $18.
obInertia: Switch from $14 to $20. - This is the same SST as obColType, but we don't need to worry about this. Only one object in the game uses both.

2. Perform Steps 2-10. If you applied my change to remove the functions that freeze objects when Sonic dies, you won't need to apply step 10. You can find it here, as well as a second step here.

3. Caterkiller's collision flags bit is overwritten by the inertia variable... meaning that Sonic cannot interact with it. Let's quickly fix this:
In 78 Caterkiller.asm, replace EVERY instance of obInertia with $1E. This is anim_frame_duration (I forget the S1 name for this variable... since I converted all of my equates to the S2 nomenclature)
If you want, you can even give $1E a new local equate for use with this object. below "Cat_Index", place this line:

cat_gvel:   = $1E       	; ground speed. (To replace the normal g_vel SST, as it is used for collision purposes)

Other than Caterkiller, I found ZERO bugs. I haven't had ANY time to do wiki work... just barely had time to squeeze in some changes to RHS' Sonic 2 Recreation page... but I'll get this up in due time.

This post has been edited by KingofHarts: 17 August 2013 - 10:26 AM

[MarkeyJester]

Congratulations on porting the system over, it's nice to see non-techies trying these things out for themselves and making good progress, well done!