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: Code (ASM): tst.b ($FFFFF7A7).w ; Is boss defeated? bne.s + ; If so, branch So you have this: Code (ASM): 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: Code (ASM): 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.
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.
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.
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: 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: 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: But if you look in the original "Sonic 3 and Knuckles", this bug is already fixed and Knuckles has no ground issues: 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: Code (ASM): 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: Code (ASM): subi.w #9,$C(a0) ; This fixes Knuckles getting stuck in the ground So, you end up with this: Code (ASM): 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.
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 Hello, I've been meaning to make this guide for ages but because of life reasons, I just didn't have the time. But recently, I have found more time and decided to get on with this. In Sonic 2, there are multiple speed issue bugs with Sonic and Tails, but for now, let's look at it with Sonic's point of view. It's uncommon, but not exactly rare, and when Super Sonic is enabled, it becomes more apparent. But sometimes, Sonic's top speed, acceleration and deceleration can be set wrong. The most common place for the bugs to occur is around this area of ARZ1 due to where the speed shoes are placed. Like said, it can be uncommon, but with people's hacks putting speedshoes underwater and other places, the bugs can happen more often. There are several speed issues: If Super Sonic and you hit speedshoes, his top speed goes a little bit higher which is fine, but his acceleration and deceleration decreases. Technically, it's applying normal Sonic's speedshoes speed. If Normal Sonic and you get speedshoes, if you go underwater, speedshoes's speed are lost. Even if you get out of the water, Sonic's speed is normal. If Super Sonic and you get speedshoes, if you go underwater, speedshoes's speed are lost. Even if you get out of the water, Super Sonic's speed is normal. If underwater and you get speedshoes, Sonic's "out-of-water" speedshoes speed apply, making you go way too fast underwater. Getting out of water or even back in and the speedshoes speeds are lost, even with speedshoes applied. If Super and underwater and you get speedshoes, Normal Sonic's "out-of-water" speedshoes speed apply, making you go way too fast underwater. Getting out of water or even back in and the speedshoes speeds are lost, even with speedshoes applied, but applies Super Sonic's speed settings. If underwater and you get speedshoes, bug above applies but if you never leave the water, once speedshoes wear off, Sonic's normal speed applies, even though you're still underwater, making you still too fast. If Super and underwater and you get speedshoes, bug above the above applies but if you never leave the water, once speedshoes wear off, Super Sonic's speed applies, even though you're still underwater, making you still too fast. If underwater and then you transform into Super Sonic, Super Sonic's "out-of-water" speed applies, making you way too fast. If you have speedshoes and then you transform into Super Sonic, Super Sonic's speed applies, making you lose speedshoes speed, making you that bit slower than you should be. If underwater when you have speedshoes and then you transform into Super Sonic, Super Sonic's "out-of-water" speed applies, and you lose your speedshoes speed. If underwater when you have speedshoes and you're Super Sonic and you transform back to normal Sonic, normal Sonic's "underwater" speed applies, making you lose your speedshoes. A lot, eh? The main issue is that the game never checks to see if you have the speedshoes applied or not. Or when becoming Super and etc, it's not checking if underwater, etc, etc. It would have to do a few checks itself to get it right and I suspect Sonic Team didn't have time to do it as it wasn't particularly important. But we're going to fix these ourselves, and it's easier than you think. Please note: I am using Xenowhirls disassembly, although this shouldn't be hard to follow if you're using the HG disassembly. Step 1 - Back-up your disassembly Like all guides you're about to follow, make a back-up before making any changes! I am also not held responsible for any troubles this may bring to your hack. Step 2 - Creating new speeds First of all, we need to make some new speed settings. Here are some of Sonic's speeds settings listed in Sonic 2 currently: Code (ASM): ; NORMAL move.w #$600,(Sonic_top_speed).w move.w #$C,(Sonic_acceleration).w move.w #$80,(Sonic_deceleration).w ; NORMAL SPEED SHOES move.w #$C00,(Sonic_top_speed).w move.w #$18,(Sonic_acceleration).w move.w #$80,(Sonic_deceleration).w ; SUPER SONIC move.w #$A00,(Sonic_top_speed).w move.w #$30,(Sonic_acceleration).w move.w #$100,(Sonic_deceleration).w ; NORMAL UNDERWATER move.w #$300,(Sonic_top_speed).w move.w #6,(Sonic_acceleration).w move.w #$40,(Sonic_deceleration).w ; SUPER SONIC UNDERWATER move.w #$500,(Sonic_top_speed).w move.w #$18,(Sonic_acceleration).w move.w #$80,(Sonic_deceleration).w As you can see, the game doesn't have speed settings for "Normal underwater with speedshoes", "Super Sonic with speedshoes" or "Super Sonic underwater with speedshoes". No wonder why all these bugs exist. Now, we have to come up with these speeds, which I have already done with some maths involved. To get "Normal underwater with speedshoes", I thought, how does normal Sonic get speedshoes speed? Well, everything is doubled except his deceleration, which stays the same. So I did the same and got this new speed setting. Code (ASM): ; NORMAL UNDERWATER SPEED SHOES move.w #$600,(Sonic_top_speed).w move.w #$C,(Sonic_acceleration).w move.w #$40,(Sonic_deceleration).w It's almost identical to Sonic's normal speed, except his deceleration is slower. To get "Super Sonic with speedshoes", I left the top speed setting it already does alone, but made it not decrease Super Sonic's acceleration and deceleration, making him that tiny bit faster: Code (ASM): ; SUPER SONIC SPEED SHOES move.w #$C00,(Sonic_top_speed).w move.w #$30,(Sonic_acceleration).w move.w #$100,(Sonic_deceleration).w To get "Super Sonic underwater with speedshoes", I followed the same method on how "Normal" does it, and got this: Code (ASM): ; SUPER SONIC UNDERWATER SPEED SHOES move.w #$A00,(Sonic_top_speed).w move.w #$30,(Sonic_acceleration).w move.w #$80,(Sonic_deceleration).w You do not need to add any of the ASM above into your hack as yet. Step 3 - Creating a new table Now we've got all our speeds, we need to convert it into a table. Which I have already done on your behalf: Code (ASM): ; =========================================================================== ; ---------------------------------------------------------------------------- ; Speed Settings Array ; This array defines what speeds the character should be set to ; ---------------------------------------------------------------------------- ; blank top_speed acceleration deceleration ; # ; Comment Speedsettings: dc.w $0, $600, $C, $80 ; $00 ; Normal dc.w $0, $C00, $18, $80 ; $08 ; Normal Speedshoes dc.w $0, $300, $6, $40 ; $16 ; Normal Underwater dc.w $0, $600, $C, $40 ; $24 ; Normal Underwater Speedshoes dc.w $0, $A00, $30, $100 ; $32 ; Super dc.w $0, $C00, $30, $100 ; $40 ; Super Speedshoes dc.w $0, $500, $18, $80 ; $48 ; Super Underwater dc.w $0, $A00, $30, $80 ; $56 ; Super Underwater Speedshoes ; =========================================================================== This will be our new table. We'll insert this into the ASM file shortly. First, let's go onto the next step. Step 4 - Creating a new subroutine to apply speeds So, we need to create a new subroutine to grab the right speed under Sonic's conditions. Here is what I come up with: Code (ASM): ; =========================================================================== ; --------------------------------------------------------------------------- ; Subroutine to collect the right speed setting for a character ; a0 must be character ; a1 will be the result and have the correct speed settings ; a2 is characters' speed ; --------------------------------------------------------------------------- ; ||||||||||||||| S U B R O U T I N E ||||||||||||||||||||||||||||||||||||||| ApplySpeedSettings: moveq #0,d0 ; Quickly clear d0 tst.w speedshoes_time(a0) ; Does character have speedshoes? beq.s + ; If not, branch addq.b #1,d0 ; Quickly add 1 to d0 + btst #6,status(a0) ; Is the character underwater? beq.s + ; If not, branch addq.b #2,d0 ; Quickly add 2 to d0 + cmpa.w #MainCharacter,a0 ; Is it Tails currently following this code? bne.s + ; If so, branch and ignore next question tst.b (Super_Sonic_flag).w ; Is the character Super? beq.s + ; If not, branch addq.b #4,d0 ; Quickly add 4 to d0 + add.b d0,d0 ; Multiply itself add.b d0,d0 ; And again add.b d0,d0 ; And again lea Speedsettings(pc,d0.w),a1 ; Load correct speed settings into a1 addq.l #2,a1 ; Increment a1 by 2 quickly move.l (a1)+,(a2)+ ; Set character's new top speed and acceleration move.w (a1),(a2) ; Set character's deceleration rts ; Finish subroutine ; =========================================================================== What this will do is ask questions like if you're underwater, have speedshoes or are Super and depending on the answers, it will add bytes to d0. Once finished with the questions, whatever d0 is, it will multiply itself 3 times. With the new result in d0 after that multiplication, it will then grab data from the table with its starting position being whatever d0 is. For example, say you're normal Sonic and underwater. After the questions, d0 should be 2. Multiply itself 3 times, d0 becomes 16. If you then look for 16 on the table, you'll see that it does indeed equal "Normal Underwater". So it got the right speed setting. So, here is our new code and table so far: Code (ASM): ; =========================================================================== ; --------------------------------------------------------------------------- ; Subroutine to collect the right speed setting for a character ; a0 must be character ; a1 will be the result and have the correct speed settings ; a2 is characters' speed ; --------------------------------------------------------------------------- ; ||||||||||||||| S U B R O U T I N E ||||||||||||||||||||||||||||||||||||||| ApplySpeedSettings: moveq #0,d0 ; Quickly clear d0 tst.w speedshoes_time(a0) ; Does character have speedshoes? beq.s + ; If not, branch addq.b #1,d0 ; Quickly add 1 to d0 + btst #6,status(a0) ; Is the character underwater? beq.s + ; If not, branch addq.b #2,d0 ; Quickly add 2 to d0 + cmpa.w #MainCharacter,a0 ; Is it Tails currently following this code? bne.s + ; If so, branch and ignore next question tst.b (Super_Sonic_flag).w ; Is the character Super? beq.s + ; If not, branch addq.b #4,d0 ; Quickly add 4 to d0 + add.b d0,d0 ; Multiply itself add.b d0,d0 ; And again add.b d0,d0 ; And again lea Speedsettings(pc,d0.w),a1 ; Load correct speed settings into a1 addq.l #2,a1 ; Increment a1 by 2 quickly move.l (a1)+,(a2)+ ; Set character's new top speed and acceleration move.w (a1),(a2) ; Set character's deceleration rts ; Finish subroutine ; =========================================================================== ; ---------------------------------------------------------------------------- ; Speed Settings Array ; This array defines what speeds the character should be set to ; ---------------------------------------------------------------------------- ; blank top_speed acceleration deceleration ; # ; Comment Speedsettings: dc.w $0, $600, $C, $80 ; $00 ; Normal dc.w $0, $C00, $18, $80 ; $08 ; Normal Speedshoes dc.w $0, $300, $6, $40 ; $16 ; Normal Underwater dc.w $0, $600, $C, $40 ; $24 ; Normal Underwater Speedshoes dc.w $0, $A00, $30, $100 ; $32 ; Super dc.w $0, $C00, $30, $100 ; $40 ; Super Speedshoes dc.w $0, $500, $18, $80 ; $48 ; Super Underwater dc.w $0, $A00, $30, $80 ; $56 ; Super Underwater Speedshoes ; =========================================================================== Step 5 - Placing your new code in your ASM file Thanks to step 4, we've got the majority of the code sorted. You now want to place that new code in your ASM file. My suggestion is to put it between Sonic and Tails object, seeming as they're both the ones that are going to use it more often. So, search for "obj02:" and place it just above. Now, if you've put the code in between Sonic and Tails like I said above, the rest of my guide should be fine, although if you do decide to insert the code elsewhere, you may get some “branch out of range” errors, which you must fix yourself. Depending on how heavy you've edited Sonic and/or Tails code, you might get these errors anyway, but they're so simple to fix. Step 6 - Replacing some old code in certain places Now we have our new code, we need to make some jumps to it. So, let's go. First, go to "Obj01_Init:". You only need to do this bit if you have checkpoints starting underwater, otherwise, you can skip this bit of the step. You MUST follow the rest of this step from when you see "************" onwards. Anyway, under the label "Obj01_Init:", find and delete these lines: Code (ASM): move.w #$600,(Sonic_top_speed).w ; set Sonic's top speed move.w #$C,(Sonic_acceleration).w ; set Sonic's acceleration move.w #$80,(Sonic_deceleration).w ; set Sonic's deceleration and replace with this Code (ASM): lea (Sonic_top_speed).w,a2 ; Load Sonic_top_speed into a2 bsr.w ApplySpeedSettings ; Fetch Speed settings "************" Under "Obj01_ChkShoes:" find and delete these lines: Code (ASM): move.w #$600,(Sonic_top_speed).w move.w #$C,(Sonic_acceleration).w move.w #$80,(Sonic_deceleration).w tst.b (Super_Sonic_flag).w beq.s Obj01_RmvSpeed move.w #$A00,(Sonic_top_speed).w move.w #$30,(Sonic_acceleration).w move.w #$100,(Sonic_deceleration).w and replace with this Code (ASM): lea (Sonic_top_speed).w,a2 ; Load Sonic_top_speed into a2 bsr.w ApplySpeedSettings ; Fetch Speed settings Next, under "Obj01_InWater:" find these lines and delete: Code (ASM): move.w #$300,(Sonic_top_speed).w move.w #6,(Sonic_acceleration).w move.w #$40,(Sonic_deceleration).w tst.b (Super_Sonic_flag).w beq.s + move.w #$500,(Sonic_top_speed).w move.w #$18,(Sonic_acceleration).w move.w #$80,(Sonic_deceleration).w + and replace with: Code (ASM): lea (Sonic_top_speed).w,a2 ; Load Sonic_top_speed into a2 bsr.w ApplySpeedSettings ; Fetch Speed settings Next, under "Obj01_OutWater:" find these lines and delete: Code (ASM): move.w #$600,(Sonic_top_speed).w move.w #$C,(Sonic_acceleration).w move.w #$80,(Sonic_deceleration).w tst.b (Super_Sonic_flag).w beq.s + move.w #$A00,(Sonic_top_speed).w move.w #$30,(Sonic_acceleration).w move.w #$100,(Sonic_deceleration).w + and replace with: Code (ASM): lea (Sonic_top_speed).w,a2 ; Load Sonic_top_speed into a2 bsr.w ApplySpeedSettings ; Fetch Speed settings Next, go to "Sonic_CheckGoSuper:" and find and delete these lines: Code (ASM): move.w #$A00,(Sonic_top_speed).w move.w #$30,(Sonic_acceleration).w move.w #$100,(Sonic_deceleration).w and replace with: Code (ASM): lea (Sonic_top_speed).w,a2 ; Load Sonic_top_speed into a2 bsr.w ApplySpeedSettings ; Fetch Speed settings Next, go to "Sonic_RevertToNormal:" and find and delete these lines: Code (ASM): move.w #$600,(Sonic_top_speed).w move.w #$C,(Sonic_acceleration).w move.w #$80,(Sonic_deceleration).w btst #6,status(a0) ; Check if underwater, return if not beq.s return_1AC3C move.w #$300,(Sonic_top_speed).w move.w #6,(Sonic_acceleration).w move.w #$40,(Sonic_deceleration).w and replace with this slightly different code: Code (ASM): lea (Sonic_top_speed).w,a2 ; Load Sonic_top_speed into a2 bra.w ApplySpeedSettings ; Fetch Speed settings and return Now onto Tails. Seeming as Tails uses the exact same speeds, we can use the exact same table. So, go to "Obj02_Init:". You only need to do this bit if you have checkpoints starting underwater, otherwise, you can skip this bit of the step. You MUST follow the rest of this step from when you see "~~~~~~~~~~~~" onwards. Anyway, under the label "Obj02_Init:", find and delete these lines: Code (ASM): move.w #$600,(Tails_top_speed).w ; set Tails' top speed move.w #$C,(Tails_acceleration).w ; set Tails' acceleration move.w #$80,(Tails_deceleration).w ; set Tails' deceleration and replace with this slightly different code: Code (ASM): lea (Tails_top_speed).w,a2 ; Load Tails_top_speed into a2 bsr.w ApplySpeedSettings ; Fetch Speed settings "~~~~~~~~~~~~" Next, go to "Obj02_ChkShoes:" and find and delete these lines: Code (ASM): move.w #$600,(Tails_top_speed).w move.w #$C,(Tails_acceleration).w move.w #$80,(Tails_deceleration).w and replace with: Code (ASM): lea (Tails_top_speed).w,a2 ; Load Tails_top_speed into a2 bsr.w ApplySpeedSettings ; Fetch Speed settings Next, find "Obj02_InWater:" and find and delete these lines: Code (ASM): move.w #$300,(Tails_top_speed).w move.w #6,(Tails_acceleration).w move.w #$40,(Tails_deceleration).w and replace with: Code (ASM): lea (Tails_top_speed).w,a2 ; Load Tails_top_speed into a2 bsr.w ApplySpeedSettings ; Fetch Speed settings Next, under "Obj02_OutWater:", find and delete: Code (ASM): move.w #$600,(Tails_top_speed).w move.w #$C,(Tails_acceleration).w move.w #$80,(Tails_deceleration).w and replace with: Code (ASM): lea (Tails_top_speed).w,a2 ; Load Tails_top_speed into a2 bsr.w ApplySpeedSettings ; Fetch Speed settings That's Tails. Let's edit the speed shoes object code. Locate label "super_shoes:" and find and delete these lines: Code (ASM): move.w #$C00,(Sonic_top_speed).w move.w #$18,(Sonic_acceleration).w move.w #$80,(Sonic_deceleration).w and replace with this new code: Code (ASM): movem.l a0-a2,-(sp) ; Move a0, a1 and a2 onto stack lea (MainCharacter).w,a0 ; Load Sonic to a0 lea (Sonic_top_speed).w,a2 ; Load Sonic_top_speed into a2 jsr ApplySpeedSettings ; Fetch Speed settings movem.l (sp)+,a0-a2 ; Move a0, a1 and a2 from stack Then finally, go to "loc_12A10" and delete these lines: Code (ASM): move.w #$C00,(Tails_top_speed).w move.w #$18,(Tails_acceleration).w move.w #$80,(Tails_deceleration).w and replace with this slightly different new code: Code (ASM): movem.l a0-a2,-(sp) ; Move a0, a1 and a2 onto stack lea (MainCharacter).w,a0 ; Load Tails to a0 lea (Tails_top_speed).w,a2 ; Load Tails_top_speed into a2 jsr ApplySpeedSettings ; Fetch Speed settings movem.l (sp)+,a0-a2 ; Move a0, a1 and a2 from stack All done. Please note, do not edit under the label "loc_3AA22:". This is the only speed settings that can be left alone. This is when Sonic jumps onto the Tornado at the end of WFZ. This code applies to Super Sonic too (so Super Sonic goes slower) but this is to stop Super Sonic over-shooting the Tornado and falling to his death. The speed only applies when Sonic is about to jump onto the plane. Be warned! If you have put in other places where you've made the characters change their speed, you'll want to edit them too! Step 7 - Fixing another bug With the above fixes applied, a new bug has been introduced. The bug? If you're Super Sonic and you die whilst Super, the "Super_Sonic_flag" will still remain set. This means, once the level restarts, the speed settings will fetch speeds with Super Sonic in mind, because of the flag. So if you go underwater or get sppedshoes, it will still think you're Super and take that into account. And if you followed the two steps for when Sonic and Tails get created, then the Super speeds will apply then too. Also whilst Super Sonic, if you pause the game and press A to quit, the flag will remain set. You could select Tails in options and Tails will have Super speeds. Anyway, let's fix this. Find "Level_ClrRam:" and directly underneath it before the ClearRAM macros, put this: Code (ASM): clr.b (Super_Sonic_flag).w There we go, all bugs should be fixed. Now, when you enter/exit water, enter/exit speedshoes and/or enter/exit Super, the speeds should all be set correctly! As per usual, here is a ROM with the bugs fixed. Cheers, redhotsonic
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: Code (ASM): ; --------------------------------------------------------------------------- ; 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: Code (ASM): 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: Code (ASM): 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: Code (ASM): 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: Code (ASM): 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.
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.
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. When super or normal? Either way, I haven't seen this bug.
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.
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: Code (ASM): 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: Code (ASM): ; 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.
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: Code (Text): 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: Code (Text): 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: Code (Text): 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: Code (Text): 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.
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.
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?
Knowing my luck, yes. The boss has been edited for the way he shoots more arrows. I tried fiddling with it, but no avail'. But if you're sure this fix definitely works, then it's a problem on my end and will look into it. Cheers, either way!
Okay, flamewing. Your fix for the ARZ glitch definitely does NOT work. I even performed the glitch in your hack: flamewing, I will send you a savestate which will perform this glitch via PM. I even tried your fix in the original S2 ROM. Still happens. Anyway, your fix was along the right lines, but not in the right place. Reason why? Well, I tried doing this instead temporarily: Code (ASM): cmpi.b #$C0,mapping_frame(a0) bne.s loc_306F8 cmpi.b #2,angle(a0) bge.s loc_306F8 With this code, Eggman will NEVER use the hammer because the angle (routine) is always 2 or more. He will just stay in one spot forever and ever. Yet, I was still able to perform this glitch. So, your fix does not work. The real fix Now, I noticed that it usually happens just a moment before he stops moving left/right. So, using your fix as a guide, I tried this instead: Code (ASM): loc_3069E: cmpi.b #8,angle(a0) beq.s loc_306AA addq.b #2,angle(a0) move.w #0,($FFFFF758).w loc_306AA: This code adds 2 to the angle (routine) just a split second before Eggman stops moving from side to side. Now I cannot get this glitch to happen. I had a savestate in my S2R game where this glitch would happened, applied this fix, and even using the savestate, the glitch will now NOT happen. Hope this helps you and many others.
Actually -- and you should have seen this coming -- I manged to reproduce the glitch with your fix applied So: The Really real fix for the ARZ boss Use both fixes at the same time. Why? Well, there are two cases that cause the boss to blast-off: one when he is stopping moving left or right and one when he is just about to start swinging his hammer. RedHotSonic's fix applies to the first case, mine applies to the second case. Now it is time to find out how many similar cases there are for Silver Sonic...
Ah, this boss is sneakier than we thought. Well, at least we can safely say it's now fixed =P lol! EDIT: Got tags wrong on quote.
How to prevent level wraps in S1, S2 and S3&K Every classic Sonic game has them: gather enough speed (or use zipping mechanisms, or debug mode), go through the left edge of the screen and bam -- you are now at the end of the level. This is how you can completely eliminate level wraps from your hack. In all cases, I am assuming the Hg disassembly; it should be easy to port it over to your favorite outdated disassembly. Sonic 1 Find the routine "Sonic_LevelBound" (it is in file "_incObj/Sonic LevelBound.asm"); it starts like this: [68k]Sonic_LevelBound: ; XREF: Obj01_MdNormal; et al move.l obX(a0),d1 move.w obVelX(a0),d0 ext.l d0 asl.l #8,d0 add.l d0,d1 swap d1 move.w (v_limitleft2).w,d0 addi.w #$10,d0 cmp.w d1,d0 ; has Sonic touched the side boundary? bhi.s @sides ; if yes, branch[/68k] Change this routine so it looks like this: [68k]Sonic_LevelBound: ; XREF: Obj01_MdNormal; et al moveq #0,d2 move.l obX(a0),d1 smi.b d2 ; Set d2 if player on position > 32767 add.w d2,d2 ; Move bit up move.w obVelX(a0),d0 spl.b d2 ; Set if speed is positive add.w d2,d2 ; Move bit up ext.l d0 asl.l #8,d0 add.l d0,d1 spl.b d2 ; Set if position+speed is < 32768 move.w (v_limitleft2).w,d0 addi.w #$10,d0 tst.w d2 ; If d2 is zero, we had an underflow of position beq.s @sides swap d1 cmp.w d1,d0 ; has Sonic touched the side boundary? bhi.s @sides ; if yes, branch[/68k] You are done. Sonic 2 Find the routine "Sonic_LevelBound"; it starts like this: [68k]; loc_1A974: Sonic_LevelBound: move.l x_pos(a0),d1 move.w x_vel(a0),d0 ext.l d0 asl.l #8,d0 add.l d0,d1 swap d1 move.w (Camera_Min_X_pos).w,d0 addi.w #$10,d0 cmp.w d1,d0 ; has Sonic touched the left boundary? bhi.s Sonic_Boundary_Sides ; if yes, branch[/68k] Change this routine so it looks like this: [68k]; loc_1A974: Sonic_LevelBound: moveq #0,d2 move.l x_pos(a0),d1 smi.b d2 ; Set d2 if player on position > 32767 add.w d2,d2 ; Move bit up move.w x_vel(a0),d0 spl.b d2 ; Set if speed is positive add.w d2,d2 ; Move bit up ext.l d0 asl.l #8,d0 add.l d0,d1 spl.b d2 ; Set if position+speed is < 32768 move.w (Camera_Min_X_pos).w,d0 addi.w #$10,d0 tst.w d2 ; If d2 is zero, we had an underflow of position beq.s Sonic_Boundary_Sides swap d1 cmp.w d1,d0 ; has player touched the left boundary? bhi.s Sonic_Boundary_Sides ; if yes, branch[/68k] Now find the routine "Tails_LevelBound" and do the same. From now on, no matter how much speed you gain, you can never go past the left boundary of the screen and do a level wrap. Sonic 3 & Knuckles Find the function "Player_Check_Screen_Boundaries"; it looks like this: [68k]Player_Check_Screen_Boundaries: move.l $10(a0),d1 move.w $18(a0),d0 ext.l d0 asl.l #8,d0 add.l d0,d1 swap d1 move.w (Camera_min_X_pos).w,d0 addi.w #$10,d0 cmp.w d1,d0 bhi.s loc_11732[/68k] Now change it to look like this: [68k]Player_Check_Screen_Boundaries: moveq #0,d2 move.l $10(a0),d1 smi.b d2 ; Set d2 if player on position > 32767 add.w d2,d2 ; Move bit up move.w $18(a0),d0 spl.b d2 ; Set if speed is positive add.w d2,d2 ; Move bit up ext.l d0 asl.l #8,d0 add.l d0,d1 spl.b d2 ; Set if position+speed is < 32768 move.w (Camera_min_X_pos).w,d0 addi.w #$10,d0 tst.w d2 ; If d2 is zero, we had an underflow of position beq.s loc_11732 swap d1 cmp.w d1,d0 bhi.s loc_11732[/68k] Now find the routine "Tails_Check_Screen_Boundaries" and do the same. You are done. So, what is going on? When computing the position to compare against the left boundary, if the speed is negative (I.e., to the left) and it is larger, in magnitude, than the current X position, applying the speed to the position causes the result to become negative, effectively becoming a large positive number. When compared to the minimum camera X + 10, it is considered a valid value. The additional code checks for this underflow in the position, and prevents it from happening.
