Sonic and Sega Retro Message Board: Some changes and fixes for Sonic 2 - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help
  • 10 Pages +
  • ◄ First
  • 7
  • 8
  • 9
  • 10
    Locked
    Locked Forum

Some changes and fixes for Sonic 2

#121 User is offline redhotsonic 

Posted 23 November 2012 - 05:15 PM

  • Also known as RHS
  • Posts: 1128
  • Joined: 31-January 05
  • Gender:Male
  • Location:United Kingdom
  • Project:Sonic 2 Recreation
  • Wiki edits:24
00

View PostKing, on 23 November 2012 - 02:26 PM, said:

Oh, here's an interesting "bug" I encounter in Sonic 2 but I don't know if it's been mentioned yet. Beat the Metropolis Zone boss without destroying any of the balloon Robotniks (you can try avoiding the balloons and beating the boss as Super Sonic or cheating with debug mode to avoid the balloons) then press the egg prison with them bouncing towards you. They start to glitch out then they all disappear when one hits you and causes you to lose your rings.


Too many sprites, that's the issue.


Anyway, to make all the little Eggman's pop when Dr Eggman himself start's flying away, go to "loc_32C66:" and just under the label, insert this:

	tst.b	($FFFFF7A7).w	; Is boss defeated?
	bne.s	+		; If so, branch



So you have this:

loc_32C66:
	tst.b	($FFFFF7A7).w	; Is boss defeated?
	bne.s	+		; If so, branch
	cmpi.b	#4,(MainCharacter+routine).w
	beq.s	loc_32C76
	cmpi.b	#4,(Sidekick+routine).w
	bne.s	loc_32C82



Then, go to "loc_32C82:" and between "cmpi.b #-2,collision_property(a0)" and "bgt.s return_32C96", insert a new label +, so you have this:

loc_32C82:
	cmpi.b	#-2,collision_property(a0)
	bgt.s	return_32C96
+
	move.b	#$14,mapping_frame(a0)
	move.b	#6,anim(a0)



Now, when you defeat the MTZ boss, as soon as Dr Eggman stops exploding then starts flying away, all remaining little Eggmans will automatically pop.

#122 User is offline King 

Posted 23 November 2012 - 05:34 PM

  • Posts: 579
  • Joined: 24-January 04
  • Gender:Male
  • Location:United States
00
Works great, thanks! I knew the balloons glitching was because of the Genesis sprite limit, but was referring to them coming after you after the boss is defeated. :P I've started applying fixes to the Xenowhirl disassembly since it seems most fixes on the wiki are geared towards it more than the SVN disassembly (most do work on both though). The only "issue" I've noticed is the Super Sonic transformation, one of the sprites (head region) becomes a garbled reddish mess while transforming. I'm not sure if it's a side effect of one of the fixes or because of the Genesis sprite limit.

EDIT: What's the proper fix for the SVN disassembly? Thinking I might apply fixes to both.
This post has been edited by King: 23 November 2012 - 06:12 PM

#123 User is offline redhotsonic 

Posted 23 November 2012 - 06:38 PM

  • Also known as RHS
  • Posts: 1128
  • Joined: 31-January 05
  • Gender:Male
  • Location:United Kingdom
  • Project:Sonic 2 Recreation
  • Wiki edits:24
00
Seems like Sonic's art is not aligned properly. Find Sonic's art (ArtUnc_Sonic:) and then above it, you should see something like "align $200". Increase it. $10000 should do fine. This will increase the ROM size quite a bit, but it fixes it. If it still appears glitched, then it might be a different bug.

#124 User is offline King 

Posted 23 November 2012 - 07:41 PM

  • Posts: 579
  • Joined: 24-January 04
  • Gender:Male
  • Location:United States
00
Appears to have fixed it, thanks! :)

#125 User is offline redhotsonic 

Posted 08 May 2013 - 04:02 PM

  • Also known as RHS
  • Posts: 1128
  • Joined: 31-January 05
  • Gender:Male
  • Location:United Kingdom
  • Project:Sonic 2 Recreation
  • Wiki edits:24
00
Okay, I haven't posted any fixes for a long time, but I just came across a bug in my hack. This isn't a bug in Sonic 2, but in Sonic 2 and Knuckles, but this wasn't worth making it's own topic. See, in my hack, all characters celebrate at the end of the act, but if I made Knuckles glide and slide on the floor, as soon as he went into the celebration stage, he was stuck in the floor like so:

Posted Image


Looking at Knuckles sliding in slow motion, he slides fine on floor, but for 1 frame only, he is in the ground by a couple of pixels:

Posted Image


But by the very next frame, he's on the floor fine. So I had to look into a fix, which I did. But I got curious. I ported Knuckles from "Sonic 2 and Knuckles", so I wondered if the bug is in there... and it is:

Posted Image


But if you look in the original "Sonic 3 and Knuckles", this bug is already fixed and Knuckles has no ground issues:

Posted Image



So, let's apply this fix. Assuming you've ported Knuckles from S2K, and haven't changed any of the official labels, go to "loc_315926:" and you should see these four commands under the label:

		move.b	$16(a0),d0
		sub.b	#$13,d0
		ext.w	d0
		add.w	d0,$C(a0)



You may comment these out (or delete them). Instead, you can put this in:

		subi.w	#9,$C(a0)			; This fixes Knuckles getting stuck in the ground



So, you end up with this:

loc_315926:					  ; ...
		move.w	#0,$14(a0)
		move.w	#0,$10(a0)
		move.w	#0,$12(a0)
;		move.b	$16(a0),d0
;		sub.b	#$13,d0
;		ext.w	d0
;		add.w	d0,$C(a0
		subi.w	#9,$C(a0)			; This fixes Knuckles getting stuck in the ground
		bsr.w	Knuckles_ResetOnFloor_Part2
		move.w	#$F,$2E(a0)
		move.b	#$22,$1C(a0)
		rts



So now, for this one single frame, it will move Knuckles up 9 pixels, so he appears on the floor correctly. As the rest of the frames were fine in the first place, no need to make any other changes.



EDIT: If anyone wants to put this on the wiki, feel free.
This post has been edited by redhotsonic: 08 May 2013 - 04:06 PM

#126 User is offline redhotsonic 

Posted 21 May 2013 - 06:04 AM

  • Also known as RHS
  • Posts: 1128
  • Joined: 31-January 05
  • Gender:Male
  • Location:United Kingdom
  • Project:Sonic 2 Recreation
  • Wiki edits:24
00
In case anyone misses my main topic when they come to fixing bugs in Sonic 2, a lot of speed bugs have got fixed by me. Main topic is here with comments, or you can just see the fix in the spoiler below:


Spoiler

#127 User is offline MoDule 

Posted 27 May 2013 - 02:03 PM

  • Posts: 308
  • Joined: 03-October 07
  • Gender:Male
  • Project:Procrastinating from writing bug-fix guides
  • Wiki edits:52
00
People are still hacking Sonic 2, right? Thought so. Anyway, down to business. Over the last few days I've been fixing a number of object-collision-related bugs. I think the first one has already been fixed, but I'll post my version anyway, since the subsequent fixes loosely rely on it.

So, lets start with the first one:

Fix ducking not properly reducing character's height during object collisions

In Sonic 2 and onwards there is a bug in the character-to-object collision checking code. Usually, when the player ducks or spin-dashes, one would expect their character's height to be reduced, but this actually only works for Sonic while he is ducking. Tails's height is never reduced, and spin-dashing doesn't do anything, either. Here, we are going to fix that.

Preparation

Before doing anything else, we'll define a macro that will come in handy later on:
; ---------------------------------------------------------------------------
; Macro to load a character's hitbox data to be used in one of the Touch routines.
;
; The formula to calculate a character's new Y radius when the top edge is moved, but the bottom
; edge should stay in the same place (e.I. when ducking) is as follows:
;	R = (D - O)/2
; where R is the new Y radius, D is the character's original diameter - 3 (32 for Sonic, 24 for
; Tails), and O is the difference between the new and old top edges. O should be an even number.
; ---------------------------------------------------------------------------
Touch_SetupSize macro
	move.w	x_pos(a0),d2		; load position into d2,d3
	move.w	y_pos(a0),d3
	subi.w	#8,d2			; assume X radius to be 8
	moveq	#0,d5
	move.b	y_radius(a0),d5
	subq.b	#3,d5			; reduce Y radius by 3
	sub.w	d5,d3			; set top of hitbox = Y pos - (Y radius - 3)

; Touch_ChkDuck:
	move.b	anim(a0),d0

; Touch_ChkDuckSonic:
	cmpi.b	#ObjID_Sonic,id(a0)	; is character Sonic?
	bne.s	Touch_ChkDuckTails	; if not, branch
	subq.b	#8,d0			; is Sonic ducking?
	beq.s	Touch_SonicDuck		; if yes, reduce height
	subq.b	#1,d0			; is Sonic spindashing?
	bne.s	Touch_NoDuck		; if not, branch

; Touch_SonicSpindash:
	addi.w	#12,d3			; move Sonic's top edge down 12 pixels...
	moveq	#(32 - 12)/2,d5		; ... and set his Y radius to 10
	bra.s	Touch_NoDuck
; ---------------------------------------------------------------------------

Touch_SonicDuck:
	addq.w	#6,d3			; move Sonic's top edge down 6 pixels...
	moveq	#(32 - 6)/2,d5		; ... and set his Y radius to 13
	cmpi.b	#$4D,mapping_frame(a0)	; is sonic fully crouched?
	bne.s	Touch_NoDuck		; if not, branch
	addq.w	#6,d3			; move Sonic's top edge down a total of 12 pixels...
	moveq	#(32 - 12)/2,d5		; ... and set his Y radius to 10
	bra.s	Touch_NoDuck
; ---------------------------------------------------------------------------

Touch_ChkDuckTails:
	subq.b	#8,d0			; is Tails ducking?
	beq.s	Touch_TailsDuck		; if yes, reduce height
	subq.b	#1,d0			; is Tails spindashing?
	bne.s	Touch_NoDuck		; if not, branch

; Touch_TailsSpindash:
	addq.w	#6,d3			; move Tails's top edge down 6 pixels...
	moveq	#(24 - 6)/2,d5		; ... and set his Y radius to 9
	bra.s	Touch_NoDuck
; ---------------------------------------------------------------------------

Touch_TailsDuck:
	addi.w	#12,d3			; move Tails's top edge down 12 pixels...
	moveq	#(24 - 12)/2,d5		; ... and set his Y radius to 6
	
Touch_NoDuck:
	move.w	#8*2,d4			; set X diameter
	add.w	d5,d5			; set Y diameter
	endm

The best place to put this macro is in s2.macros.asm. As for what this macro does, it's basically the first part of TouchResponse with a few modifications to fix the character height bug. This adds checks for ducking, and spin-dashing, as well as for Sonic's first ducking frame. What this code does in the original is set up a number of registers with coordinate, and radius values. The registers we're interested in are d3, and d5, which hold the character's bounding box's upper edge, and y-radius, respectively. The interesting part starts at Touch_ChkDuck. Since we'll be potentially checking for a number of animations, we load the current character's anim into d0. Then we check the character's id. For each of the characters, we check for the relevant animation numbers, and reduce their height if a specific animation is playing.

Extending the macro

Some users might want to do a little more with this code, like add extra animation checks, or make it work with more characters. Here I'll provide a few explanations on how to do most of the changes necessary.

To extend this code for even more characters, such as Knuckles, we will add a few lines to Touch_ChkDuckTails. Note how we make a check for Sonic's object-id at the beginning of Touch_ChkDuckSonic? We can do the same right after the label Touch_ChkDuckTails: check for the next character's id, and branch to that character's setup code if necessary. When doing this, place the extra character's code before Touch_NoDuck, as the code following it is expected to be at the end. This can be repeated for any number of characters. Note that after every extension, an unconditional branch (bra) to Touch_NoDuck needs to be added at the end of the previous character's code. For example, if we added Knuckles as a third character, we'd add a check for his id at the beginning of Touch_ChkDuckTails, add code for handling his animations before Touch_NoDuck, and then we'd need to add a branch to Touch_NoDuck at the end of the code after Touch_TailsDuck and before Touch_NoDuck.

To add additional animation checks, go to the beginning of the character-specific code. For Sonic, this would be at Touch_ChkDuckSonic. This is where we check for specific animations. Note how I used a series of subqs. That's only because it's slightly faster than using cmpi, and happens to work in this instance. Unless you understand how this works, I'd suggest you stick to using cmpi, and place your own checks in front of mine, to make sure everything still works afterwards. The animation handlers (Touch_SonicSpindash, Touch_SonicDuck, etc.) all basically work the same way: add something to d3, and overwrite d5. This is also where to do mappings-frame-specific checks, like in Touch_SonicDuck. The value to add to d3 is how many pixels the character's hitbox should be moved down; the value to write to d5 is calculated with the formula provided in the macro's documentation. Note that D is based on what the character's height would normally be, and that this isn't always the character's standing height, like while jumping.

Note

The macro can be changed into a subroutine, if that is more desirable. Note that using a macro, and calling a subroutine work differently.

Fixing the bug

Now that the macro is ready, we can get on with fixing the bug. First, go to TouchResponse(loc_3F554). Note that a portion of the code here looks a lot like our macro, as mentioned earlier. Now replace the following code:
	move.w	x_pos(a0),d2 ; load Sonic's position into d2,d3
	move.w	y_pos(a0),d3
	subi.w	#8,d2
	moveq	#0,d5
	move.b	y_radius(a0),d5
	subq.b	#3,d5
	sub.w	d5,d3
	cmpi.b	#$4D,mapping_frame(a0)	; is Sonic ducking?
	bne.s	Touch_NoDuck		; if not, branch
	addi.w	#$C,d3
	moveq	#$A,d5
; loc_3F592:
Touch_NoDuck:
	move.w	#$10,d4
	add.w	d5,d5

with the macro Touch_SetupSize. To use a macro, all we have to do is write its name, and indent it like we would with any opcode. Like this:
Label:		; labels are not indented
	Touch_SetupSize	; macros are indented, like other code

	; other code

Now all we have to do is repeat this step for Touch_Boss, Check_CNZ_bumpers, and Touch_Rings. Note that Touch_Rings has two lines inserted before the end of the code we are replacing:
	move.w	#6,d1	; set ring radius
	move.w	#12,d6	; set ring diameter

These two lines should not be removed. Also note that Check_CNZ_bumpers is slightly different in that it assumes a slightly larger x radius. It subtracts 9 from d2 instead of 8, and subsequently sets d4 to 18 instead of 16. The macro can't do this on its own (without a slight rewrite), so for now, add this after the macro in Check_CNZ_bumpers:
	subq.w	#1,d2		; X radius is larger by 1 in this routine
	moveq	#18,d4		; ... which means the diameter is larger by 2

This adjusts d2 and d4 to use the correct values again.

And with that, we are done.

The bug explained

The problem is quite simple. The original collision checking routine was only written with Sonic 1 in mind. In that game, Sonic only had a single ducking frame, so checking only for that frame is the natural solution. Sonic 2 however introduced a second character, Tails, Sonic has a second ducking frame, and both characters can perform the spin-dash. Unfortunately, it looks like the old collision checking code was never updated to account for this, thus making Tails unable to duck under things, Sonic only getting a height reduction during his final ducking frame, and both characters getting hit while spin-dashing by objects that would appear to go over them.

Afterthoughts

The new code can quickly bloat up into monstrous proportions when adding new characters, or animations. Ignoring size, the execution time can also increase. While speed isn't much of an issue here, it can become one when we start using this macro too often, like we will be doing in a later guide. My (as of yet unimplemented) solution to this is to have the character objects calculate their hitbox coordinates and radii inside their own code, and save these values somewhere in RAM. That way, the calculation only needs to be done once per character, as opposed to once per hitbox check. Building on this, we could eliminate the calculation altogether by using a table that maps every mappings frame to a pair of bounding box offsets and radii, but this would be difficult to do without a dedicated editor.

End of guide

As an aside, I recently made an addendum to a guide in my own topic, here. I had to switch two lines around, because there'd be a specific case when it doesn't behave correctly, otherwise. Speaking of my topic, should it just be merged with this one? It was originally meant to become what this topic here is, but forgot to make the suggestion, so now it just looks like a self-glorifying ego trip.

Anyway, there's a few more guides coming, so watch this space.
This post has been edited by MoDule: 27 May 2013 - 04:25 PM

#128 User is offline Dracula 

Posted 27 May 2013 - 03:15 PM

  • Posts: 590
  • Joined: 03-March 03
  • Gender:Male
  • Location:I'm watching you!
  • Project:Learning NES 6502 and hacking NES ROMs.
  • Wiki edits:12
00
While I was playing Sonic 2 a long time ago, on Wing Fortress Zone at the end, Sonic tries to jump on the tornado and for some reason, he keep on jumping to his death. Not sure if this a bug or not.

#129 User is offline redhotsonic 

Posted 27 May 2013 - 03:20 PM

  • Also known as RHS
  • Posts: 1128
  • Joined: 31-January 05
  • Gender:Male
  • Location:United Kingdom
  • Project:Sonic 2 Recreation
  • Wiki edits:24
00

View PostMoDule, on 27 May 2013 - 02:03 PM, said:

Now all we have to do is repeat this step for Touch_Boss, and Touch_Rings



Don't forget the CNZ bumpers at loc_174DE. Although, it might not be necessary. I think using a subroutine would be better rather than a macro. Using a subroutine may be ever-so slightly longer, it will save a ton of space. Personal preference I suppose. Nice work either way, it's a bit cleaner than the earlier fix in this topic.



View PostDracula, on 27 May 2013 - 03:15 PM, said:

While I was playing Sonic 2 a long time ago, on Wing Fortress Zone at the end, Sonic tries to jump on the tornado and for some reason, he keep on jumping to his death. Not sure if this a bug or not.



When super or normal? Either way, I haven't seen this bug.
This post has been edited by redhotsonic: 27 May 2013 - 03:22 PM

#130 User is offline Dracula 

Posted 27 May 2013 - 03:27 PM

  • Posts: 590
  • Joined: 03-March 03
  • Gender:Male
  • Location:I'm watching you!
  • Project:Learning NES 6502 and hacking NES ROMs.
  • Wiki edits:12
00

Quote

When super or normal? Either way, I haven't seen this bug.


Both!

#131 User is offline MoDule 

Posted 27 May 2013 - 04:18 PM

  • Posts: 308
  • Joined: 03-October 07
  • Gender:Male
  • Project:Procrastinating from writing bug-fix guides
  • Wiki edits:52
00

View Postredhotsonic, on 27 May 2013 - 03:20 PM, said:

Don't forget the CNZ bumpers at loc_174DE. Although, it might not be necessary.

Oops, for some reason, I thought those worked differently. Turns out, I was wrong. I'll fix it right away. This is why it's good to share these things.
This post has been edited by MoDule: 27 May 2013 - 04:18 PM

#132 User is offline MoDule 

Posted 28 May 2013 - 10:29 AM

  • Posts: 308
  • Joined: 03-October 07
  • Gender:Male
  • Project:Procrastinating from writing bug-fix guides
  • Wiki edits:52
00
A new day, a new guide.
... Actually, this one probably could have been a part of yesterday's guide, but oh well.

Today we will be performing an arguably more useful fix than yesterday: we'll make it so that characters can duck under solid objects. I actually already made a fix for this a long time ago, but it was messy, and I never made it public.

Fix incorrect solid object collisions while ducking

In all of the main series 16-bit Sonic games, there's a bug where ducking has no effect on solid object collisions. When checking the lower boundary of a solid object, characters will always behave as if they were standing, unless they are rolling. Here, we are going to fix that.

Fixing the bug

First, locate the label SolidObject_cont(loc_199E8). This is the part of the solid object code that performs the hitbox checks. The relevant code looks like this:
loc_199F0:
	; We now perform the x portion of a bounding box check.  To do this, we assume a
	; coordinate system where the x origin is at the object's left edge.
	move.w	x_pos(a1),d0		; load Sonic's x position...
	sub.w	x_pos(a0),d0		; ... and calculate his x position relative to the object
	add.w	d1,d0			; assume object's left edge is at (0,0).  This is also Sonic's distance to the object's left edge.
	bmi.w	loc_19AC4		; branch, if Sonic is outside the object's left edge
	move.w	d1,d3
	add.w	d3,d3			; calculate object's width
	cmp.w	d3,d0
	bhi.w	loc_19AC4		; branch, if Sonic is outside the object's right edge
	; We now perform the y portion of a bounding box check.  To do this, we assume a
	; coordinate system where the y origin is at the highest y position relative to the object
	; at which Sonic would still collide with it.  This point is
	;   y_pos(object) - width(object)/2 - y_radius(Sonic) - 4,
	; where object is stored in (a0), Sonic in (a1), and height(object)/2 in d2.  This way
	; of doing it causes the object's hitbox to be vertically off-center by -4 pixels.
	move.b	y_radius(a1),d3		; load Sonic's y radius
	ext.w	d3
	add.w	d3,d2			; calculate maximum distance for a top collision
	move.w	y_pos(a1),d3		; load Sonic's y position...
	sub.w	y_pos(a0),d3		; ... and calculate his y position relative to the object
	addq.w	#4,d3			; assume a slightly lower position for Sonic
	add.w	d2,d3			; assume the highest position where Sonic would still be colliding with the object to be (0,0)
	bmi.w	loc_19AC4		; branch, if Sonic is above this point
	andi.w	#$7FF,d3
	move.w	d2,d4
	add.w	d4,d4			; calculate minimum distance for a bottom collision
	cmp.w	d4,d3
	bhs.w	loc_19AC4		; branch, if Sonic is below this point

Right after the third line from the bottom which calculates the minimum distance for a bottom collision, add the following code:
; Solid_ChkDuck:
	move.b	anim(a1),d5

; Solid_ChkDuckSonic:
	cmpi.b	#ObjID_Sonic,id(a1)	; is character Sonic?
	bne.s	Solid_ChkDuckTails	; if not, branch
	subq.b	#8,d5			; is Sonic ducking?
	beq.s	Solid_SonicDuck		; if yes, branch
	subq.b	#1,d5			; is Sonic spindashing?
	bne.s	Solid_NoDuck		; if not, branch

; Solid_SonicSpindash:
	subi.w	#12,d4			; reduce object's downward radius by 12
	bra.s	Solid_NoDuck
; ---------------------------------------------------------------------------

Solid_SonicDuck:
	subq.w	#6,d4			; reduce object's downward radius by 6
	cmpi.b	#$4D,mapping_frame(a1)	; is sonic fully crouched?
	bne.s	Solid_NoDuck		; if not, branch
	subq.w	#6,d4			; reduce object's downward radius by a total of 12
	bra.s	Solid_NoDuck
; ---------------------------------------------------------------------------

Solid_ChkDuckTails:
	subq.b	#8,d5			; is Tails ducking?
	beq.s	Solid_TailsDuck		; if yes, branch
	subq.b	#1,d5			; is Tails spindashing?
	bne.s	Solid_NoDuck		; if not, branch

; Solid_TailsSpindash:
	subq.w	#6,d4			; reduce object's downward radius by 6
	bra.s	Solid_NoDuck
; ---------------------------------------------------------------------------
	
Solid_TailsDuck:
	subi.w	#12,d4			; reduce object's downward radius by 12

Solid_NoDuck:

With this, the bug is fixed.

Extending functionality

There might be cases when the user wants to add additional animation checks, or characters. Doing this works much like extending the Touch_SetupSize macro, as described here. The only difference is that what you would add to d3 in the other guide, you'd subtract from d4 here. So if for example you wanted to reduce Tails's height while ducking by 12, here you subtract 12 from d4, as seen in Solid_TailsDuck. You also do not need to set d5 to anything, since it's not used here.

Afterthoughts

The extra overhead produced by the additional checks is multiplied by the number of solid objects on screen. This can lead to the game incurring slowdown earlier than it would normally. My proposed solution, as seen in the other guide here, is to calculate character hitbox information inside the character's code, and save it in RAM, thus eliminating the need to calculate it for every solid object's collision check.

End of guide

I know there's a few other solid object routines that I didn't touch. If someone knows what these specific routines are used for, and if they need to be fixed, too, please let me know.

#133 User is offline flamewing 

Posted 11 August 2013 - 02:29 PM

  • Emerald Hunter
  • Posts: 831
  • Joined: 11-October 10
  • Gender:Male
  • Location:Brasil
  • Project:Sonic Classic Heroes; Sonic 2 Special Stage Editor; Sonic 3&K Heroes (on hold)
  • Wiki edits:12
31

View PostBSonirachi, on 08 August 2012 - 06:07 PM, said:

Perhaps someone might be able to fix up this game-stopping glitch which sometimes happens when destroying this boss:

http://www.youtube.c...feature=related


This is the same bug that causes the ARZ boss to shoot out when you land the last hit on a specific frame. The fix for both is similar, too, so here they go:

Fixing the Silver Sonic glitch
Go to loc_3984A; there, you will find the following code:
loc_3984A:
	bsr.w	loc_39CAE
	bsr.w	loc_39D1C
	subq.b	#1,objoff_2A(a0)
	beq.s	loc_39886

and change it to this:
loc_3984A:
	bsr.w	loc_39CAE
	bsr.w	loc_39D1C
	cmpi.b	#$C,routine(a0)
	beq.w	JmpTo45_DisplaySprite
	subq.b	#1,objoff_2A(a0)
	beq.s	loc_39886

and it will be fixed.

Fixing the ARZ boss bug
Go to loc_306B8, where you will find the following code:
loc_306B8:
	bsr.w	Boss_MoveObject
	bsr.w	loc_3075C
	bsr.w	loc_30824
	cmpi.b	#-$40,mapping_frame(a0)
	bne.s	loc_306F8
	lea	(Boss_AnimationArray).w,a1

and change it to this:
loc_306B8:
	bsr.w	Boss_MoveObject
	bsr.w	loc_3075C
	bsr.w	loc_30824
	cmpi.b	#$C0,mapping_frame(a0)
	bne.s	loc_306F8
	cmpi.b	#8,angle(a0)
	beq.s    loc_306F8
	lea	(Boss_AnimationArray).w,a1

and it will be fixed.

So what exactly is going on?
For the ARZ code, 'angle(a0)' is the equivalent of 'routine(a0)' for most other objects: it selects which branch of the code to execute. In both cases, the functions called before the added code check to see if the boss was defeated and sets routine/angle to the right value for this case. Then, the normal flow of code does other stuff that adds 2 to routine/angle (as the case may be). For the ARZ boss, this puts him in the flying away mode; for Silver Sonic, this turns him into the rockets he uses when coming down. The new branches skip over the code that would cause these errors.
This post has been edited by flamewing: 21 August 2013 - 08:45 PM

#134 User is offline redhotsonic 

Posted 11 August 2013 - 03:36 PM

  • Also known as RHS
  • Posts: 1128
  • Joined: 31-January 05
  • Gender:Male
  • Location:United Kingdom
  • Project:Sonic 2 Recreation
  • Wiki edits:24
00
Is that it? It's that simple? Thanks very much for the ARZ fix; I'll be applying it now. Shame the bug is still in my release for the SHC, but hey ho! Thanks again :)


EDIT: This hasn't fixed the ARZ bug for me. He can still leave early.
This post has been edited by redhotsonic: 23 August 2013 - 03:38 PM

#135 User is offline flamewing 

Posted 23 August 2013 - 05:52 PM

  • Emerald Hunter
  • Posts: 831
  • Joined: 11-October 10
  • Gender:Male
  • Location:Brasil
  • Project:Sonic Classic Heroes; Sonic 2 Special Stage Editor; Sonic 3&K Heroes (on hold)
  • Wiki edits:12
31
The only changes I have in this boss other than the one above are: fix for laughing when players are hit; destruction fix from up thread; changes for S3&K priority and my hybrid object manager; Hg synch. None of these affect anything related, and I can't perform the blast-off in my hack despite getting the final hit in all possible frames (I am a TASer, so...).

Maybe some change you made to the boss is conflicting with the fix?
  • 10 Pages +
  • ◄ First
  • 7
  • 8
  • 9
  • 10
    Locked
    Locked Forum

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users