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
  • 16 Pages +
  • ◄ First
  • 3
  • 4
  • 5
  • 6
  • 7
  • Last ►
    Locked
    Locked Forum

Some changes and fixes for Sonic 2

#61 User is offline Esrael 

Posted 18 June 2012 - 08:13 PM

  • Posts: 186
  • Joined: 24-July 03
  • Gender:Male
  • Location:Brazil, São Paulo, Guarulhos
  • Project:Neto Assembler Editor / Sonic 2 Delta / Neto Boot Loader
Here is another fix from rev 2.
Tornado Spindash death.

Find:
  loc_3A7DE:
   ......

        bsr.w	JmpTo27_SolidObject
	bsr.w	loc_3AE3A
	move.b	objoff_2E(a0),d0
	move.b	status(a0),d1
	andi.b	#8,d0    ; <---------- Change this line 
	andi.b	#8,d1    ; <---------- Change this line 
	eor.b	d0,d1
	move.b	d1,objoff_2E(a0)
	lea	(MainCharacter).w,a1 ; a1=character
	move.w	x_pos(a1),d1
	move.w	(Camera_X_pos).w,d0
	move.w	d0,(Camera_Min_X_pos).w




Change #8 to #1 and you can do spindash in Tornado.

  loc_3A7DE:
   ...... 

        bsr.w	JmpTo27_SolidObject
	bsr.w	loc_3AE3A
	move.b	objoff_2E(a0),d0
	move.b	status(a0),d1
	andi.b	#1,d0    ; <---------- Change this line 
	andi.b	#1,d1    ; <---------- Change this line 
	eor.b	d0,d1
	move.b	d1,objoff_2E(a0)
	lea	(MainCharacter).w,a1 ; a1=character
	move.w	x_pos(a1),d1
	move.w	(Camera_X_pos).w,d0
	move.w	d0,(Camera_Min_X_pos).w




And Another bug with Miles in ARZ Boss.
If you stand in one arrow with Sonic the arrow will fall, but not with Miles.
How To fix

Find:
loc_30CCC:
        ......

        btst	#3,status(a0)
	beq.s	return_30D02
	move.w	#$1F,objoff_30(a0)

loc_30CF4:



and change to

loc_30CCC:
       ......
;------------------------------------------------------------------------------- 
        btst    #$04, status(A0)
        beq.s   Not_Miles_In_Arrow
        move.w  #$001F, objoff_30(A0)  
Not_Miles_In_Arrow:
;------------------------------------------------------------------------------- 
        btst	#3,status(a0)
	beq.s	return_30D02
	move.w	#$1F,objoff_30(a0)

loc_30CF4:


Done.
This post has been edited by Esrael: 18 June 2012 - 10:44 PM

#62 User is offline KingofHarts 

Posted 19 June 2012 - 01:19 AM

  • Posts: 1608
  • Joined: 07-August 10
  • Gender:Male
  • Project:Project Sonic 8x16
  • Wiki edits:1
I wanna touch back on the CPZ boss for a second. There is a minor bug that occurs when you die against the boss. If you or Tails die against the boss, and are under the solid floor, the character will hit the floor and just drop, instead of the proper behavior. Now, I have no problem with said bug... but just noting that its there.

#63 User is offline Esrael 

Posted 19 June 2012 - 08:19 PM

  • Posts: 186
  • Joined: 24-July 03
  • Gender:Male
  • Location:Brazil, São Paulo, Guarulhos
  • Project:Neto Assembler Editor / Sonic 2 Delta / Neto Boot Loader

View PostKingofHarts, on 19 June 2012 - 01:19 AM, said:

I wanna touch back on the CPZ boss for a second. There is a minor bug that occurs when you die against the boss. If you or Tails die against the boss, and are under the solid floor, the character will hit the floor and just drop, instead of the proper behavior. Now, I have no problem with said bug... but just noting that its there.


This is not a boss error. This effect can occur in any place with solity over Sonic Head like the location in the following picture.

Posted Image
Edit: Using debug and moving left will case the problem reported.

This is not necessary a bug (I think), but you can use the following code to disable floor detection while dying.
find:
; loc_1E596:
Floor_ChkTile:
	move.w	d2,d0
        ....
	movea.l	d1,a1
	rts
; ===========================================================================
; precalculated values for Floor_ChkTile
; (Sonic 1 calculated it every time instead of using a table)
word_1E5D0:



and insert the following code:

; loc_1E596:
Floor_ChkTile:
	move.w	d2,d0
        ....
	movea.l	d1,a1
        cmpi.b  #$06, $0024(A0)  
        bne.s   Player_Not_Death  

        cmpi.b  #$01, (A0)          ; Is Sonic  
        beq.s   Player_Death       ; 
        cmpi.b  #$02, (A0)          ;  Is Miles
        bne.s   Player_Not_Death ;  
Player_Death:                         ; 

        move.l  #$FFFF0000, A1                                                                   
Player_Not_Death:
	rts
; ===========================================================================
; precalculated values for Floor_ChkTile
; (Sonic 1 calculated it every time instead of using a table)
word_1E5D0:



This code will point to the first tile in RAM which have no solidity. Since Sonic object can't find solidity will show the dying animation.

Edit: Correct check. The Current Character is in A0
Edit: Metal Sonic Fall Bug caused by new code.
This post has been edited by Esrael: 21 June 2012 - 08:44 PM

#64 User is offline KingofHarts 

Posted 20 June 2012 - 01:10 AM

  • Posts: 1608
  • Joined: 07-August 10
  • Gender:Male
  • Project:Project Sonic 8x16
  • Wiki edits:1
Sweet deal, Esrael! BTW should the address be A0? or a0?
You have A0 and A1 with capital letters. Shouldn't they be lower case? or it doesn't matter?

#65 User is offline redhotsonic 

Posted 20 June 2012 - 01:33 AM

  • Also known as RHS
  • Posts: 1571
  • Joined: 31-January 05
  • Gender:Male
  • Location:United Kingdom
  • Project:Sonic Bash!
  • Wiki edits:24

View PostKingofHarts, on 20 June 2012 - 01:10 AM, said:

Sweet deal, Esrael! BTW should the address be A0? or a0?
You have A0 and A1 with capital letters. Shouldn't they be lower case? or it doesn't matter?



It's not case-sensitive so it doesn't matter what you put. As long as you get the number right.

#66 User is offline KingofHarts 

Posted 20 June 2012 - 01:57 AM

  • Posts: 1608
  • Joined: 07-August 10
  • Gender:Male
  • Project:Project Sonic 8x16
  • Wiki edits:1
Disable floor collision while dying - Nice add... I must say. I'm gonna go ahead and see if I can be the one to put this in Sonic 1 on my own...

Going to add more to the wiki today.

#67 User is offline redhotsonic 

Posted 20 June 2012 - 01:42 PM

  • Also known as RHS
  • Posts: 1571
  • Joined: 31-January 05
  • Gender:Male
  • Location:United Kingdom
  • Project:Sonic Bash!
  • Wiki edits:24
I might as well post another



How to fix monitors' collision



There's a bug in Sonic 2 that's not in any other game. The monitor's collision. Well, I say collision, but it's actually fine. It's the touch_collision that's actually wrong.


The thing is, in the original Sonic 2 game, it's very hard to spot this bug. Mainly because the monitors are all placed on a flat floor. But whereas many of us have change the level layout of our hacks, some of you may of placed them on hills or slopes (or at the beginning/end of slopes/hills), the bug may be noticeable.



The bug? You go straight through the monitors without destroying it. This can be a pain in the ass.

The bad thing about it is, if you've placed a monitor on a hill but near a wall, there's a great chance you can go through that wall. This isn't meant to happen obviously.



To demonstrate, I have enabled debug and put a monitor in the air. I have now ran and jumped to it.

Posted Image

Posted Image



If you come from either side of the monitor, but Sonic going up, you will go through the monitor. That's why this bug is more common on hills/slopes. If you're rolling up a hill into the side of the monitor, chances are you'll go through it without destroying it.

Posted Image



; loc_3F73C:
Touch_Monitor:
	tst.w	y_vel(a0)	; is Sonic moving upwards?
	bpl.s	loc_3F768	; if not, branch
	move.w	y_pos(a0),d0
	subi.w	#$10,d0
	cmp.w	y_pos(a1),d0
	bcs.s	return_3F78A
	neg.w	y_vel(a0)	; reverse Sonic's y-motion
	move.w	#-$180,y_vel(a1)
	tst.b	routine_secondary(a1)
	bne.s	return_3F78A
	move.b	#4,routine_secondary(a1) ; set the monitor's routine counter
	rts




It does this because there are checks to see if you've hit the bottom of the monitor and if so, to knock the monitor (hit a monitor directly underneath, you know what I mean). But if you go through the sides, it does this check, and it thinks you've missed the bottom when going up to hit it from underneath. Because of this, it branches to an rts.

In the code above, it asks if you're moving up and if not, branch away to destroy the monitor. But if moving up, it's doing the check to see if you're going to hit the bottom of the monitor. If you do, it will reverse Sonic's y_vel, and change the routine of the monitor so it can be knocked and fall. BUT, if you miss the bottom, it will branch to "return_3F78A" which is an rts. So, if you're hitting the side of the monitor but in an upwards state, it will branch to the rts; making Sonic go through the monitor and not breaking it. As soon as Sonic's y_vel hits 0 or more (starts to fall down), the monitor will break, because of the very first command.



So, we need to make the monitor breakable by hitting the side of it but still going up. Here's how. Go to the code I just showed you above, and change it to this:


; loc_3F73C:
Touch_Monitor:
	tst.w	y_vel(a0)	; is Sonic moving upwards?
	bpl.s	loc_3F768	; if not, branch
	move.w	y_pos(a0),d0
	subi.w	#$10,d0
	cmp.w	y_pos(a1),d0
	bcs.s	loc_3F768	; Changed to loc_3F768 instead of return_3F78A
	neg.w	y_vel(a0)	; reverse Sonic's y-motion
	move.w	#-$180,y_vel(a1)
	tst.b	routine_secondary(a1)
	bne.s	return_3F78A
	move.b	#4,routine_secondary(a1) ; set the monitor's routine counter
	rts


All we've done here is changed "return_3F78A" to "loc_3F768". So now, when moving up but hitting the sides of the monitor, instead of it branching to "rts", it branches to the "break monitor" coding!


Posted Image

Posted Image


As you can see in the pictures, you will now destroy them. You can still hit the bottom of the monitor and it will knock over. Any other way of hitting the monitor remains unaffected.



Done.






Additional step you might want to take


It's now fixed, but there remains one design flaw (which is actually present in S3K). You know when you hit the monitor, like jumping on it, Sonic's y_vel negates, so he appears to bounce. But with our new fix, if you destroy the monitor from the sides going up, Sonic's y_vel still negates, so he shoots down. It does this in S3K also. To me, this looks unnatural. If you like this, ignore this step. If you don't want Sonic's y_vel to negate when going up, but still to negate when going down, it's simple to do so.


Go to "loc_3F768:" and you should see this:

loc_3F768:
	cmpa.w	#MainCharacter,a0
	beq.s	+
	tst.w	(Two_player_mode).w
	beq.s	return_3F78A
+
	cmpi.b	#2,anim(a0)
	bne.s	return_3F78A
	neg.w	y_vel(a0)	; reverse Sonic's y-motion
	move.b	#4,routine(a1)
	move.w	a0,parent(a1)

return_3F78A:
	rts


See that? It's negating Sonic's y_vel no matter what when you destroy the monitor. We don't want it to when we're going up, we want to carry on going up. So, change it to this:

loc_3F768:
	cmpa.w	#MainCharacter,a0
	beq.s	+
	tst.w	(Two_player_mode).w
	beq.s	return_3F78A
+
	cmpi.b	#2,anim(a0)
	bne.s	return_3F78A
	tst.w	y_vel(a0)	; is Sonic moving upwards?
	blt.s	+		; if so, branch, we want Sonic to carry on moving up
	; So, Sonic is moving down instead?
	neg.w	y_vel(a0)	; reverse Sonic's y-motion, to give him that bounce off the monitor
+
	move.b	#4,routine(a1)
	move.w	a0,parent(a1)

return_3F78A:
	rts



Now, it checks if you're moving up, and if so, do NOT negate Sonic's y_vel. If you're moving down, it won't branch, and negate his y_vel, giving him his bounce.


All done!




Cheers,
redhotsonic





EDIT: I might as well explain. This bug is only in Sonic 2. In Sonic 1, it branches to a subroutine to make the sides of the monitor completely solid, but you can't destroy the monitor still. In Sonic 3 and Knuckles, the coding for hitting the monitor underneath no longer exists. If you hit it underneath in S3K, it will get destroyed. So no bug there.
This post has been edited by redhotsonic: 20 June 2012 - 01:45 PM

#68 User is offline Tiddles 

Posted 20 June 2012 - 02:23 PM

  • Diamond Dust
  • Posts: 471
  • Joined: 25-December 09
  • Gender:Male
  • Location:Leicester, England
  • Project:Get in an accident and wake up in 1973
  • Wiki edits:31
Although if you implement it in S3K and keep the code to destroy the monitor from below instead of dropping it, not bouncing back down might look a bit funny.

My "fix" for this in Sonic 3 Complete is a bit different - if Sonic is on the ground, I use the S&K behaviour, I.e. he can roll through anything regardless of angle. If he's in the air, I use essentially Sonic 1 style behaviour where the sides are treated as solid, because I detest the way you can just jump straight sideways into a monitor in S&K rather than having to go over and land on it. However, I'm not actually too happy with how the solid sides stuff is working, at least my implementation of it (some interesting effects can happen when landing around multiple monitors without rolling), and it may later be reverted to Sonic 2/3A style behaviour in the air, where it's technically possible to jump through - but it's such a rare case in the air that I'm not too troubled by it.

Incidentally, I'm pretty sure it is possible to have this bug affect you in vanilla Sonic 3, though you are unlikely to see it without special effort. At the start of CNZ2, there are three monitors suspended in a room a long way above the bottom of the first diagonal barber pole thingy. Tails can fly up there and knock them down to the ground below, which will cause them to land on slopes where it's possible to spindash through them.

A question about one of the previous fixes. For the ARZ arrows, you suggest making the code faster by using a cmpi.b to check for Sonic's ducking animation rather than a cmpi.w to check the real frame, which slightly changes the behaviour in that Sonic additionally becomes immune during his partially-crouched state. My question - and I feel like this is something I should probably know if I have a green badge, but so what - is whether that saves any notable number of cycles in reality, particularly given the tradeoff that it changes the intended behaviour of the game? I would not normally choose such a tradeoff but I might be swayed if the optimisation is genuinely worthwhile.

#69 User is offline redhotsonic 

Posted 20 June 2012 - 02:48 PM

  • Also known as RHS
  • Posts: 1571
  • Joined: 31-January 05
  • Gender:Male
  • Location:United Kingdom
  • Project:Sonic Bash!
  • Wiki edits:24

View PostTiddles, on 20 June 2012 - 02:23 PM, said:

My question - and I feel like this is something I should probably know if I have a green badge, but so what - is whether that saves any notable number of cycles in reality, particularly given the tradeoff that it changes the intended behaviour of the game? I would not normally choose such a tradeoff but I might be swayed if the optimisation is genuinely worthwhile.




It's entirely your choice which you pick. The off-frame only happens for a split second, and pretty much not noticeable. It DOES save a fair bit of time in reality. Reason why:

        cmpi.b  #9,anim(a0)             ; is Sonic spindashing?
        beq.s   Duckinganddashing       ; if so, branch
;-------------------------------------------------------------------------------              
        cmpi.b  #$02, (A0)              ; Is Miles?
        bne.s   Touch_Check_Sonic       ; Not goto Sonic routine
        cmpi.b  #$5B, mapping_frame(A0) ; is Miles ducking
        bne.s   Touch_NoDuck                  
        bra.s   Duckinganddashing
Touch_Check_Sonic:
;-------------------------------------------------------------------------------   
        cmpi.b  #$4D,mapping_frame(a0)  ; is Sonic ducking?
        bne.s   Touch_NoDuck            ; if not, branch
Duckinganddashing:              ; So, Sonic is spindashing or ducking
        addi.w  #$C,d3
        moveq   #$A,d5
; loc_3F592:
Touch_NoDuck:


Imagine you're Sonic, and you hold the down button to crouch. Imagine Tails is following you, he copies your controls, so he's also crouching.


Esrael's way:

Sonic: It asks if you're spindashing, and then if you are, branch. As we're not, it continues. Are you Tails? Nope, let's branch. Is Sonic ducking? Yes, do not branch.

Tails: It asks if you're spindashing, and then if you are, branch. As we're not, it continues. Are you Tails? Yes! Continue, is he ducking? Yes! So do not branch. Then branch to the ducking routine.



This has got to be repeated for both Sonic and Tails every single frame. And that's touch_response only. It's also got to do this again for BOTH Sonic and Tails in the ring code! So, it's doing it 4 times in a frame. Then if you're in CNZ, for the bumpers, it's got to do it again for both of them, that's 6 times every frame! It's got to keep asking if you're Tails, and it's got to do more branches.




My way:

        cmpi.b  #9,anim(a0)             ; is Sonic spindashing?
        beq.s   Duckinganddashing       ; if so, branch
        cmpi.b  #8,anim(a0)             ; is Sonic ducking?
        bne.s   Touch_NoDuck            ; if not, branch
Duckinganddashing:              ; So, Sonic is spindashing or ducking
        addi.w  #$C,d3
        moveq   #$A,d5
; loc_3F592:
Touch_NoDuck:



Again, imagine you're Sonic, and you hold the down button to crouch. Imagine Tails is following you, he copies your controls, so he's also crouching.


Sonic: It asks if you're spindashing, and then if you are, branch. As we're not, it continues. Are you ducking? Yes, do not branch and do the routine.

Tails: Exactly the same.



Basically, mine has saved it from asking if you're Tails all the time and stopping it from branching here and there. It may not look much, but seeming as it has to do this for BOTH Sonic and Tails every single frame, same with rings and if CNZ, the bumpers, my way will save it a fair few cycles.


Posted Image

Seeming as Sonic is like this for only a split second, I think my way is better. In my hack, I've got it set to the coding I've shown. And I've never noticed any difference to what is was like before. But it all depends on preference. If you don't like this fact (or even knowing it), then Esrael's way is the way to go. But it just will take a little tiny bit longer.


If going Esrael's way, the slowdown probably won't be noticeable unless near water or in it, or when you lose a lot of rings.




EDIT: In fact, in S3K, this is completely gone from the game. It doesn't bother shortening his y_radius when ducking or spindashing. I guess they've done this to save cycles. And the other reason is because there isn't really any point you would "duck" to avoid anything. I tried placing the shooting arrow (from that head object in Marble Garden Zone) and tried avoiding it by ducking, and when it's about to miss you, it still hurts you. The checks isn't present in the touch_response, the rings collision or the boss (obviously no bumbers from CNZ).
This post has been edited by redhotsonic: 20 June 2012 - 03:16 PM

#70 User is offline flamewing 

Posted 20 June 2012 - 04:20 PM

  • Emerald Hunter
  • Posts: 1135
  • Joined: 11-October 10
  • Gender:Male
  • Location:🇫🇷 France
  • Project:Sonic Classic Heroes; Sonic 2 Special Stage Editor; Sonic 3&K Heroes (on hold)
  • Wiki edits:12
Well, I will now go forth and backport these fixes into my hack. Esrael and RHS, you both have made you way into the Special Thanks section of the credits.

#71 User is offline redhotsonic 

Posted 21 June 2012 - 05:31 AM

  • Also known as RHS
  • Posts: 1571
  • Joined: 31-January 05
  • Gender:Male
  • Location:United Kingdom
  • Project:Sonic Bash!
  • Wiki edits:24

View Postflamewing, on 20 June 2012 - 04:20 PM, said:

Well, I will now go forth and backport these fixes into my hack. Esrael and RHS, you both have made you way into the Special Thanks section of the credits.


Cool, I know that means I've done well.



Can I suggest something to any admin or staff? Can this topic be pinned? That way in the future, all members will see this and can spot these bug fixes and apply them, making further Sonic 2 hacks bug-ridden. Just a suggestion.

#72 User is offline Jayextee 

Posted 21 June 2012 - 05:42 AM

  • Comic Mischief
  • Posts: 3215
  • Joined: 22-October 07
  • Gender:Male
  • Location:Kathmandu, Nepal
  • Project:I DONE MAKED GAMES.
  • Wiki edits:27

View Postredhotsonic, on 21 June 2012 - 05:31 AM, said:

Can this topic be pinned? That way in the future, all members will see this and can spot these bug fixes and apply them, making further Sonic 2 hacks bug-ridden.


Don't you mean 'bug-fixed'? ;)

#73 User is offline redhotsonic 

Posted 21 June 2012 - 06:33 AM

  • Also known as RHS
  • Posts: 1571
  • Joined: 31-January 05
  • Gender:Male
  • Location:United Kingdom
  • Project:Sonic Bash!
  • Wiki edits:24
What I meant was that all future hacks will have got "rid" of all the bugs we've mentioned. Not all hacks in the future will be "ridden" with bugs =P

#74 User is offline Overlord 

Posted 21 June 2012 - 02:38 PM

  • Substitute Meerkovo IT Chief
  • Posts: 16825
  • Joined: 12-January 03
  • Gender:Male
  • Location:Berkshire, England
  • Project:VGDB
  • Wiki edits:3,204

View Postredhotsonic, on 21 June 2012 - 05:31 AM, said:

Can I suggest something to any admin or staff? Can this topic be pinned? That way in the future, all members will see this and can spot these bug fixes and apply them, making further Sonic 2 hacks bug-ridden. Just a suggestion.

To be fair, this is the sort of thing the SCHG is for...

#75 User is offline Esrael 

Posted 21 June 2012 - 08:42 PM

  • Posts: 186
  • Joined: 24-July 03
  • Gender:Male
  • Location:Brazil, São Paulo, Guarulhos
  • Project:Neto Assembler Editor / Sonic 2 Delta / Neto Boot Loader

View PostEsrael, on 19 June 2012 - 08:19 PM, said:

View PostKingofHarts, on 19 June 2012 - 01:19 AM, said:

I wanna touch back on the CPZ boss for a second. There is a minor bug that occurs when you die against the boss. If you or Tails die against the boss, and are under the solid floor, the character will hit the floor and just drop, instead of the proper behavior. Now, I have no problem with said bug... but just noting that its there.


...

; loc_1E596:
Floor_ChkTile:
	move.w	d2,d0
        ....
	movea.l	d1,a1
        cmpi.b  #$06, $0024(A0)  
        bne.s   Player_Not_Death  
        move.l  #$FFFF0000, A1                                                                   
Player_Not_Death:
	rts
; ===========================================================================
; precalculated values for Floor_ChkTile
; (Sonic 1 calculated it every time instead of using a table)
word_1E5D0:



This code will point to the first tile in RAM which have no solidity. Since Sonic object can't find solidity will show the dying animation.

Edit: Correct check. The Current Character is in A0


View PostKingofHarts, on 20 June 2012 - 01:10 AM, said:

Sweet deal, Esrael! BTW should the address be A0? or a0?
You have A0 and A1 with capital letters. Shouldn't they be lower case? or it doesn't matter?


While testing and playing I have found a bug with Metal Sonic. He will fall forever since he can't detect the floor, because his initial animation use same id as Sonic and Miles while dying. To fix add the following lines to code:

; loc_1E596:
Floor_ChkTile:
	move.w	d2,d0
        ....
	movea.l	d1,a1
;--------------------------------------
        cmpi.b  #$06, $0024(A0)  
        bne.s   Player_Not_Death  
        cmpi.b  #$01, (A0)          ; Is Sonic  
        beq.s   Player_Death       ; 
        cmpi.b  #$02, (A0)          ;  Is Miles
        bne.s   Player_Not_Death ;  
Player_Death:                         ; 
        move.l  #$FFFF0000, A1                                                                   
Player_Not_Death:
;---------------------------------------
	rts
; ===========================================================================
; precalculated values for Floor_ChkTile
; (Sonic 1 calculated it every time instead of using a table)
word_1E5D0:



The following explanation is for Sonic 2 rev 2.
About Metal Sonic, there is a very well know bug in Sonic 2 rev 2 (see image). But there is another in rev 2 which is not noticed with Grabber enemy legs (see image)
Posted Image

The following code is shared between Metal Sonic and Grabber enemy

Code from Sonic 2 rev 1
loc_367AA:
	move.b	render_flags(a0),d0
	andi.b	#$FC,d0
	move.b	status(a0),d2
	andi.b	#$FC,d2
	move.b	render_flags(a1),d1
	andi.b	#3,d1
	or.b	d1,d0
	or.b	d1,d2
	move.b	d0,render_flags(a0)
	move.b	d2,status(a0)
	rts



Code from Sonic 2 rev 2 which cause Metal Sonic and Grabber enemy legs bug
Offset_0x0361D0: ; Usado pelo objeto 0xA7 - Grabber
                move.b  $0001(A0), D0
                andi.b  #$FD, D0         ; <----------- #$FC in rev 1
                move.b  $0022(A0), D2
                andi.b  #$FD, D2         ; <----------- #$FC in rev 1
                move.b  $0001(A1), D1
                andi.b  #$02, D1          ; <----------- #$03 in rev 1
                or.b    D1, D0
                or.b    D1, D2
                move.b  D0, $0001(A0)
                move.b  D2, $0022(A0)
                rts



Why this code was changed???
This post has been edited by Esrael: 21 June 2012 - 08:43 PM

  • 16 Pages +
  • ◄ First
  • 3
  • 4
  • 5
  • 6
  • 7
  • Last ►
    Locked
    Locked Forum

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