CNZ's bumpers are prone to very well hidden bug, which will trigger if you move your data around a lot or try optimising the code near SpecialCNZBumpers_Act1. The bug is that the large bumpers no longer bounce Sonic or Tails off of them. There doesn't seems to be any collision-related effects at all: no sound, nothing. I personally found this bug when I changed the nearby 'jmp (PlaySound).l' to a 'jmp (PlaySound).w'. Boy, was I surprised to find that was the cause of my problem! The bumpers' layout files contain entries that are 6 bytes in size. Two dummy entries are needed for the bumper manager to function properly: one at the beginning, and one at the end. I believe the first dummy needs an X-pos of $0000, while the last one needs $FFFF. Now, CNZ act 2's bumpers file starts and ends with dummy entries, but act 1... it doesn't start with one. In fact, the jmp right before the binclude just happens to have $0000 in the same place as an entry's X-pos (jmp $0000XXXX), so it works. This could have been a real goofy space optimisation by Sonic Team. To fix this, you just gotta shove 6 blank bytes in the beginning of the CNZ act 1 bumper layout file. Tada. However, there is a 'better' way. By exploiting the bumper manager's logic, you can shave some bytes off: First off, remove the first two bytes of your new blank dummy entry at the beginning of your file. Then, find the pointer to SpecialCNZBumpers_Act1, and just append a '-2' to the end of the address. The first byte of information is unneeded as only the X-pos is of any use to dummy entries. Next, the dummy entry at the end of the file can also be trimmed. It should be '0000FFFF0000'. You can remove the last two bytes. Again, we only need the X-pos. You can also apply this to act 2's file.
I haven't provided any fixes for a while; mainly due to the fact I hardly hack at all these days, you know, with real life getting in the way. Anyway, I was playing Sonic 2 the other day and realised a fair few issues with the MCZ boss. You may consider these bugs, you may not, but to me, they're not right. Eggman will stop moving sideways on the floor when he hurts Tails, then goes back up into the ground (stop-and-drill routine), yet he won't do any of this when he hits Sonic. Unless he hits Tails to go into the stop-and-drill routine, Eggman will not laugh when he hits Sonic OR Tails. If Sonic alone or Tails alone, Eggman won't laugh or enter the stop-and-drill routine at all. When Eggman comes to the floor, he turns and aims for Sonic every time. This is fine the first time round when the boss starts as he starts in the middle, but the rest of the time he spawns on the sides; you don't want him turning ideally. Screen still shakes when you're dead, a bit weird since everything else like the falling rocks have come to a standstill. MCZ boss doesn't actually start in the middle of the screen (design choice more than a bug). When Eggman comes to the floor when he first starts, he turns and aims for Sonic but never for Tails (again, more of a design change than a bug). So there's at least 5 bugs; 7 if you want to make the design changes. Let's get coding! I'm using Xenowhirl's disassembly as a guide. Spoiler Yeah, yeah, shoot me now, if your newer disassembly is so much better, you'll have no issues applying this anyway Step 1 - Making the "stop-and-drill" routine occur every time Sonic and Tails are hurt Eggman finding it funny when Tails is hit Not so much when Sonic is hurt though Go to "loc_3124A:" and you'll see this: Code (ASM): loc_3124A: subi.w #1,($FFFFF75C).w cmpi.w #$28,($FFFFF75C).w bgt.w loc_312E8 move.b #1,($FFFFF73F).w tst.w ($FFFFF75C).w bpl.w loc_312E8 tst.b objoff_38(a0) beq.s loc_31274 sf objoff_38(a0) bra.s loc_31298 See the "tst.b objoff_38(a0)" bit? From there, delete it all. So now you have a gap between "bpl.w loc_312E8" and "loc_31274:". The code you just deleted, we're going to replace with this: Code (ASM): cmpi.b #4,(MainCharacter+routine).w ; Did Sonic (or Sonic alone or Tails alone) get hit? bge.s + ; If so, branch cmpi.b #4,(Sidekick+routine).w ; Did Tails (Sidekick) get hit? blt.s loc_31274 ; If not, branch away + sf objoff_38(a0) ; Set the stop-and-drill routine bra.s loc_312A2 ; And branch to take effect So you'll end up with this: Code (ASM): loc_3124A: subi.w #1,($FFFFF75C).w cmpi.w #$28,($FFFFF75C).w bgt.w loc_312E8 move.b #1,($FFFFF73F).w tst.w ($FFFFF75C).w bpl.w loc_312E8 cmpi.b #4,(MainCharacter+routine).w ; Did Sonic (or Sonic alone or Tails alone) get hit? bge.s + ; If so, branch cmpi.b #4,(Sidekick+routine).w ; Did Tails (Sidekick) get hit? blt.s loc_31274 ; If not, branch away + sf objoff_38(a0) ; Set the stop-and-drill routine bra.s loc_312A2 ; And branch to take effect ; =========================================================================== loc_31274: Now, Eggman will enter his "stop-and-drill" routine every time Sonic and Tails have been hit. Yet, he won't laugh at all anymore. That's the next bit. Step 2 - Make Eggman laugh every time Sonic or Tails has been hit Suddenly Eggman isn't in a laughing mood Go to "loc_31298:" Code (ASM): loc_31298: lea ($FFFFF740).w,a1 move.b #$30,7(a1) This bit of coding is no longer being used after what we just did in Step 1. Good, this is in a bad place really. If we left the code we changed to branch here, Eggman will indeed laugh when Sonic and Tails have been hit, but only when he changes into his "stop-and-drill routine". Meaning, if you get hit when he has stopped, or when he is about to drill, or is coming down from drilling, whatever, he still will not laugh. Anyway, delete the two lines under the label "loc_31298:". We're moving it. Because the label no longer exists, directly above is a branch to the label to what used to be underneath. This is illegal (most assemblers will create a "nop" to avoid this but still). So under "loc_31288:", delete this line: Code (ASM): bra.s loc_312A2 So, you'll end up with this: Code (ASM): loc_31288: cmpi.w #$2200,($FFFFF750).w blt.s loc_312E8 move.w #$2200,($FFFFF750).w ; =========================================================================== loc_312A2: move.w #0,($FFFFF758).w move.b #0,angle(a0) lea ($FFFFF740).w,a1 andi.b #$F0,2(a1) ori.b #$B,2(a1) andi.b #$F0,8(a1) ori.b #$B,8(a1) move.b #0,1(a1) andi.b #$F0,6(a1) ori.b #$D,6(a1) move.w #$64,($FFFFF75C).w move.w #-$C0,($FFFFF75A).w Next, go to "loc_31470:" and directly below this label, insert this code: Code (ASM): cmpi.b #4,(MainCharacter+routine).w ; Did Sonic (or Sonic alone or Tails alone) get hit? bge.s + ; If so, branch cmpi.b #4,(Sidekick+routine).w ; Did Tails (Sidekick) get hit? blt.s ++ ; If not, branch away + lea ($FFFFF740).w,a1 ; Load Eggman's face animation into a1 cmpi.b #$30,7(a1) ; Is Eggman laughing already? bgt.s + ; If so, branch, and do not reset move.b #$30,7(a1) ; Start Eggman's laughing animation + So you'll end up with this: Code (ASM): loc_31470: cmpi.b #4,(MainCharacter+routine).w ; Did Sonic (or Sonic alone or Tails alone) get hit? bge.s + ; If so, branch cmpi.b #4,(Sidekick+routine).w ; Did Tails (Sidekick) get hit? blt.s ++ ; If not, branch away + lea ($FFFFF740).w,a1 ; Load Eggman's face animation into a1 cmpi.b #$30,7(a1) ; Is Eggman laughing already? bgt.s + ; If so, branch, and do not reset move.b #$30,7(a1) ; Start Eggman's laughing animation + cmpi.b #8,angle(a0) bcc.s return_314B6 tst.b objoff_32(a0) beq.s loc_314B8 tst.b collision_flags(a0) bne.s return_314B6 tst.b objoff_14(a0) bne.s loc_3149A move.b #$20,objoff_14(a0) move.w #$AC,d0 jsr (PlaySound).l Now, every time you're hurt, at any point during the boss, Eggman will laugh, like he is meant to! The reason why we check to see if Eggman is already laughing is because when set, a countdown gets set and counts down 1 every frame. But as soon as it goes down by 1, without the check, it'll set the counter back to 30 and it'll do this for every frame until you fall on the floor. Because of this, Eggman will display the laughing face but won't actually animate, because the counter is stuck on 30. Doing this check will set it to 30, but then it will let it countdown like it is meant to, making his laugh animate. That's the first 3 bugs fixed already after 2 steps! Eggman now a bit happier Sonic is hurt and decides to stop and prepare his drills Eggman really is happier now Step 3 - Stop the screen shaking when dead When you die in this boss, like all other bosses and when in normal levels, nearly everything comes to a standstill. In this boss, rings, Eggman, and the falling rocks comes to a standstill. Yet, if you die when the screen was shaking, it will continue to shake. It looks awfully weird that the screen continues to shake yet the falling rocks have stopped mid-air. Let's fix this. Go to "loc_CD54:" (which is nothing to do with the MCZ boss code, but with MCZ layer deformation), and after where you see: Code (ASM): loc_CD54: swap d0 moveq #6,d6 bsr.w loc_D940 move.w ($FFFFEE0C).w,($FFFFF618).w moveq #0,d2 tst.b ($FFFFEEBD).w beq.s + Insert this: Code (ASM): lea (MainCharacter).w,a1 ; Load the Main Character into a1 cmpi.b #6,routine(a1) ; is the Main Character dead? bcc.s + ; if so, branch and skip shaking So you end up with this: Code (ASM): loc_CD54: swap d0 moveq #6,d6 bsr.w loc_D940 move.w ($FFFFEE0C).w,($FFFFF618).w moveq #0,d2 tst.b ($FFFFEEBD).w beq.s + lea (MainCharacter).w,a1 ; Load the Main Character into a1 cmpi.b #6,routine(a1) ; is the Main Character dead? bcc.s + ; if so, branch and skip shaking move.w (Timer_frames).w,d0 andi.w #$3F,d0 lea SwScrl_RippleData(pc),a1 lea (a1,d0.w),a1 moveq #0,d0 move.b (a1)+,d0 add.w d0,(Vscroll_Factor).w add.w d0,($FFFFF618).w add.w d0,($FFFFEEF4).w move.b (a1)+,d2 add.w d2,($FFFFEEF0).w + This will stop the screen shaking when you die if it was already shaking. BUT WAIT, the screen shaking noise is still present, let's stop that. Go to "LevEvents_MCZ2_Routine4:" (which is nothing to do with the layer deformation code, but with MCZ's level events), after: Code (ASM): LevEvents_MCZ2_Routine4: tst.b ($FFFFEEBD).w beq.s + Again, insert this: Code (ASM): lea (MainCharacter).w,a1 ; Load the Main Character into a1 cmpi.b #6,routine(a1) ; is the Main Character dead? bcc.s + ; if so, branch and skip shaking noise So you end up with this: Code (ASM): LevEvents_MCZ2_Routine4: tst.b ($FFFFEEBD).w beq.s + cmpi.b #6,(MainCharacter+routine).w ; is Sonic dead? bcc.s + ; if so, branch and skip shaking noise move.w (Timer_frames).w,d0 andi.w #$1F,d0 bne.s + move.w #$E1,d0 bsr.w JmpTo3_PlaySound + This will stop the noise happening when you die. Step 4 - Disable Eggman from turning and facing Sonic when on the side of the screen Eggman locates Sonic, but he won't do too much You can argue this isn't a bug, but I believe it is. Eggman spawns on the left side of the screen facing right. If you're to the left of him (hugging the left screen), he will turn and try to move, then pretty much go into his "stop-and-drill" routine pretty quickly because he doesn't move anywhere (this happens even without the first 3 bugs we've just fixed). Eggman is on the left and is facing right, let him go right. This happens on the other side of the screen too (As seen in the picture). Luckily, the fix is very simple! Go to "loc_311AA:". After the "move.b #$30,1(a1)" line, insert this: Code (ASM): cmpi.w #$21A0,($FFFFF750).w ; Only aim for Sonic at the beginning (so he doesn't turn on the side of the screen) bne.s loc_31210 ; First time coming down? Ah, aim then When Eggman comes down at the beginning of the boss fight, he spawns in the middle; #$21A0 being his X co-ordinate. So what it is doing here, is if Eggman is at this position, then do NOT branch and aim for Sonic. The rest of the time when he comes down, he'll be at the left or right of the screen. So, he won't be in this X co-ordinate anymore. Therefore, he will no longer aim for Sonic. So, if he spawns on the left, he will be facing right, and he'll go right! That's more like it Step 5 - Make Eggman actually start in the middle of the screen (optional) No, not quite centre This is more of a design choice, but could be considered a bug. I just find it weird that he spawns just too little to the right of the centre of the screen. Anyway, simple fix if you want him dead centre. Go to "loc_30FB8:" and 4th line down, change: Code (ASM): move.w #$21A0,x_pos(a0) to this: Code (ASM): move.w #$2190,x_pos(a0) ; Make Eggman start dead-centre of the screen He'll now start in the centre instead. BUT WAIT! Did you follow step 4? If so, step 4 will no longer work, so go back to "loc_311AA:" and change: Code (ASM): cmpi.w #$21A0,($FFFFF750).w ; Only aim for Sonic at the beginning (so he doesn't turn on the side of the screen) to this: Code (ASM): cmpi.w #$2190,($FFFFF750).w ; Only aim for Sonic at the beginning (so he doesn't turn on the side of the screen) And step 4 won't need to be re-done. Eggman likes to be precise with his entrance Step 6 - Make Eggman at the beginning aim for Tails too (optional) Again, design choice. When Eggman comes down at the beginning, he faces and aims for Sonic. Completely ignores Tails. Strange that at first he only used to laugh when he hit Tails and not care about Sonic. What we're going to do here is when Eggman comes down, whoever is closest, he will aim and go for! At "loc_311AA:" and after "bclr #0,render_flags(a0)" you'll see this code: Code (ASM): move.w (MainCharacter+x_pos).w,d0 sub.w ($FFFFF750).w,d0 bmi.s loc_31210 bset #0,render_flags(a0) Delete it. And replace it with this: Code (ASM): ; Check who is closer out of Sonic or Tails move.w (MainCharacter+x_pos).w,d0 ; Move Sonic's x_pos into d0 move.w (Sidekick+x_pos).w,d1 ; Move Tails's x_pos into d1 move.w ($FFFFF750).w,d2 ; Move Eggman's x_pos into d2 move.w d2,d3 ; Move Eggman's x_pos into d3 sub.w d0,d2 ; Subtract Sonic's x_pos from Eggman's bpl.s + ; If result is a positive, branch neg.w d2 ; As the result is a negative, negate it to positive + sub.w d1,d3 ; Subtract Tails's x_pos from Eggman's bpl.s + ; If result is a positive, branch neg.w d3 ; As the result is a negative, negate it to positive + cmp.w d2,d3 ; Is Sonic Closer? bgt.s + ; If so, branch ; Tails is closer cmpi.b #6,(Maincharacter+routine).w ; dead? bge.s + ; As Tails is dead, ignore Tails and aim for Sonic sub.w ($FFFFF750).w,d1 bmi.s loc_31210 bset #0,render_flags(a0) bra.s loc_31210 + ; Sonic is closer sub.w ($FFFFF750).w,d0 bmi.s loc_31210 bset #0,render_flags(a0) So, you'll end up with this: Code (ASM): loc_311AA: bsr.w loc_2D5DE cmpi.w #$660,($FFFFF754).w blt.s loc_31228 move.w #$660,($FFFFF754).w addq.b #2,angle(a0) lea ($FFFFF740).w,a1 andi.b #$F0,2(a1) ori.b #6,2(a1) andi.b #$F0,8(a1) ori.b #6,8(a1) andi.b #$F0,6(a1) ori.b #$D,6(a1) move.b #$20,5(a1) move.w #$64,($FFFFF75C).w move.b #$30,1(a1) cmpi.w #$2190,($FFFFF750).w ; Only aim for Sonic at the beginning (so he doesn't turn on the side of the screen) bne.s loc_31210 ; First time coming down? Ah, aim then bclr #0,render_flags(a0) ; Check who is closer out of Sonic or Tails move.w (MainCharacter+x_pos).w,d0 ; Move Sonic's x_pos into d0 move.w (Sidekick+x_pos).w,d1 ; Move Tails's x_pos into d1 move.w ($FFFFF750).w,d2 ; Move Eggman's x_pos into d2 move.w d2,d3 ; Move Eggman's x_pos into d3 sub.w d0,d2 ; Subtract Sonic's x_pos from Eggman's bpl.s + ; If result is a positive, branch neg.w d2 ; As the result is a negative, negate it to positive + sub.w d1,d3 ; Subtract Tails's x_pos from Eggman's bpl.s + ; If result is a positive, branch neg.w d3 ; As the result is a negative, negate it to positive + cmp.w d2,d3 ; Is Sonic Closer? bgt.s + ; If so, branch ; Tails is closer cmpi.b #6,(Maincharacter+routine).w ; dead? bge.s + ; As Tails is dead, ignore Tails and aim for Sonic sub.w ($FFFFF750).w,d1 bmi.s loc_31210 bset #0,render_flags(a0) bra.s loc_31210 + ; Sonic is closer sub.w ($FFFFF750).w,d0 bmi.s loc_31210 bset #0,render_flags(a0) loc_31210: move.w #-$200,($FFFFF758).w move.w #0,($FFFFF75A).w btst #0,render_flags(a0) beq.s loc_31228 neg.w ($FFFFF758).w Eggman will now aim for whoever is closer out of Sonic and Tails. Because you followed step 4, this will only do it when the boss starts (unless you didn't do step 5, and if you didn't, make sure you change the: Code (ASM): cmpi.w #$2190,($FFFFF750).w ; Only aim for Sonic at the beginning (so he doesn't turn on the side of the screen) back to it's normal: Code (ASM): cmpi.w #$21A0,($FFFFF750).w ; Only aim for Sonic at the beginning (so he doesn't turn on the side of the screen) so this step takes effect). Tails is a lot closer, think Eggman will go for him instead Step 7 - Quick branch fix Chances are your disassembly will come with an out-of-reach error. At "loc_311AA:", change: Code (ASM): blt.s loc_31228 to: Code (ASM): blt.w loc_31228 All done. That's all bugs fixed!
This is some pretty cool stuff... that said the only one I take issue with is having him always face the opposite side he comes down on when he's at the end of the screen. You basically made him go into empty space like a total derp. Outside of that, excellent stuff. Great to see you back RHS.
How do you mean? Where have I made him come down in an empty space? Except from making him start dead centre at the beginning only, the rest of his "coming down" places haven't changed. In the normal S2(even after these fixes), if you're closer to the right side, Eggman will spawn on the left and face right, ready to come at you. Vice versa if you're at the left (if this is what you mean?).
(Ripped largely from ReadySonic) Ever get snared in a bridge while in debug mode? Obviously, those things don't make any attempt to avoid interacting with the player while in debug mode, while many other objects do. First up, let's fix up the debug object itself: go to Debug_Init and, below the 'move.b #AniIDSonAni_Walk,anim(a0)', add this: Code (ASM): btst #3,status(a0) ; is Sonic standing on an object? beq.s + ; if not, branch bclr #3,status(a0) ; clear Sonic's standing flag move.b interact(a0),d0 ; get object ID clr.b interact(a0) ; clear object ID lsl.w #6,d0 addi.w #Object_RAM,d0 movea.w d0,a2 bclr #3,status(a2) ; clear object's standing flag + Since Sonic and certain objects keep track of if they're being touched, and what by, we need to clear all that when entering debug mode. Without this additional fix, our fix would cause another bug where bridges stay deformed when entering debug mode. Next up, the bridge itself. sub_F872 is what handles deforming the bridge, and changing the player's Y position accordingly. Since AI Tails doesn't enter debug mode with the player, we don't want to ignore the entire subroutine; only the part involving the main character. Above 'lea (MainCharacter).w,a1', add this check: Code (ASM): tst.w (Debug_placement_mode).w bne.s +++ Now we need to mess with those annoying nameless labels. Add a '+' before the 'rts', and change the 'blo.s ++' to 'blo.s +++'.
Xenowhirl conversion powers activate! For the above: Go to Debug_Main and under this line in loc_41AAE: Code (ASM): move.b #0,anim(a0) Paste this: Code (ASM): btst #3,status(a0) ; is Sonic standing on an object? beq.s + ; if not, branch bclr #3,status(a0) ; clear Sonic's standing flag move.b interact(a0),d0 ; get object ID clr.b interact(a0) ; clear object ID lsl.w #6,d0 addi.w #Object_RAM,d0 movea.w d0,a2 bclr #3,status(a2) ; clear object's standing flag + And above: Code (ASM): lea (MainCharacter).w,a1 ; a1=character subq.b #1,d6 moveq #$3F,d5 + Paste this: Code (ASM): tst.w (Debug_placement_mode).w bne.s ++ Now just add a + before the rts and you're done. =)
Because how dare I expect Xeno users to have their own skills in porting. How about porting the other fifty non-Xeno guides first, preferably without turning them into copy/paste guides? I've pushed a commit to the Git disasm to make it more obvious, but this easily applies to Xeno, as well. clearRAM, in S2, at least, is used incorrectly quite a lot: the amount of data to clear is sometimes 4 bytes too big. This can lead to problems stemming from small bits of RAM being accidentally cleared, such as this error with flamewing's DMA queue. Spotting these bugged clearRAMs is easy. Seriously, spot the bugged ones in this block: Code (ASM): clearRAM Sprite_Table,$284 ; Sprite attribute table buffer clearRAM Horiz_Scroll_Buf,$404 ; H scroll table buffer, $404 bytes clearRAM PNT_Buffer,$C04 ; PNT buffer clearRAM Sprite_Table_Input,$400 clearRAM Object_RAM,$2000 ...which, in latest Git, has become this: Code (ASM): ; These '+4's shouldn't be here; clearRAM accidentally clears an additional 4 bytes clearRAM SS_Sprite_Table,(SS_Sprite_Table_End-SS_Sprite_Table)+4 clearRAM SS_Horiz_Scroll_Buf_1,(SS_Horiz_Scroll_Buf_1_End-SS_Horiz_Scroll_Buf_1)+4 clearRAM SS_Misc_Variables,(SS_Misc_Variables_End-SS_Misc_Variables)+4 clearRAM SS_Sprite_Table_Input,(SS_Sprite_Table_Input_End-SS_Sprite_Table_Input) clearRAM SS_Object_RAM,(SS_Object_RAM_End-SS_Object_RAM) On a related note, under Level_ClrRam, CNZ_saucer_data has $100 bytes cleared, even though only $40 are used (an AND ensures it). Also, RingsManager_Setup, only $40 bytes of Ring_consumption_table is cleared, even though it's $80 bytes in size.
The exact same issue occurs with Sonic 1. In the "ClearScreen" routine specifically, both clear loops clear one long-word extra, as the value loaded to the data register does not take into account the nature of the dbf instruction. I'll tell you what, I'm glad you're taking the time to fix bugs such as this, as these are the vital ones that are potentially game breaking.
Hm. I am wondering if the clearRAM macro should not be changed to take starting and ending addresses instead of start address and length. For one, it would simplify the expressions a lot…
I started looking into the VDP, and I think Horiz_Scroll_Buf can be reduced to $380 bytes. For one, S&K does this. Two, only $380 bytes of Horiz_Scroll_Buf is DMA'd to VRAM. This is down to how HScroll is configured: it's in 'per-scanline' mode, so there's a word of data for each line on each of plane A and plane B, totalling (224 * 2 * 2) $380. I'm not sure how PAL ties into this. Looking at each level's SwScrl code, the ones I can understand, anyway, they only seem to modify the first $380, too. In fact, OOZ starts at the $380 mark, working up. EDIT: Actually, it seems CPZ affects $3C0 bytes.
Now that you mention it, I might contribute to this topic as well. Fixing the CPZ deformation routine In both Sonic 1 and Sonic 2, exactly $400 bytes are allocated for the Horizontal Scroll RAM buffer, although only the first $380 bytes are transferred and affect the actual screen. For more information, refer to Clownacy's post above. As it has been already explained, the buffer can be reduced to $380 bytes, freeing the whole $80 bytes for you. Most of background scrolling/deformation routines are indeed designed to fill exactly the first $380 bytes of the buffer, leaving no overhead. However, the routine for Chemical Plant zone is special. It's written in such a way that it mistakenly fills up to $3C0 bytes under certain circumstances. Since all the data past first $380 bytes of the buffer is unused, it can be considered that there are programming errors in the original algorithm, as it seems to fill the buffer with different overhead (if I recall correctly). However, the programmer let it be, since the HSRAM buffer itself was allocated with certain overhead to begin with. In order to fix that, find SwScrl_CPZ and replace all its code with this: http://pastebin.com/yWdtnRbU This is an alternative deformation routine I wrote back in 2012 by request. Although re-written for the most part, it should be pixel-perfectly identical to the original CPZ scrolling. Now, that CPZ deformation algorithm is upgraded and fixed, you can go to s2.constants.asm and change this: Code (Text): Horiz_Scroll_Buf: ds.b $400 into this: Code (Text): Horiz_Scroll_Buf: ds.b $380 EDIT: Clownacy's post quoted due to a new page.
Ah, yes, the CPZ deformation code. I mentioned it a few times in IRC. For reference, what the code does (both the original and vladik's version) is split the background into 3 different regions: the top 228 lines scroll with Camera_BG_X_pos, the next 16 lines scroll with Camera_BG_X_pos plus a ripple effect, and the remainder scrolls with Camera_BG2_X_pos. This simple description belies the monstrous complexity of the original code, which does not correctly account for the number of lines it generates, leading to the noted overflow. Here is a visual aid. Edit: after taking a look at vladik's code, the compulsive optimizer in me basically forced me to do this. Also guaranteed never to exceed the bounds of the HScroll table, and probably leaves stock code in the dust.
Speaking of background deformation in general, and I apologize if this had been mentioned in the past... is there any substantial documentation on how that works at all? I made a duplicate GHZ in Sonic 1 to serve as Bridge Zone, and am trying to make a background that would be 3 chunks tall as opposed to two... Needless to say this breaks the level... I know nothing about how the background handling works... Kinda derailing but perhaps if it also applies to Sonic 2 as well than it can contribute to Sonic 2 discussion.
Not publicly, at least as far as I am aware. I have been doing some work on that regard, but haven't released anything (yet). What I can tell you, though, is that S1's deformation code is a mess, and S2's deformation code is a clusterfuck. Anyway: new fix for S1/S2: Fixing collisions with objects from below Anyone that has tried porting Knuckles' climbing (or a similar ability) to S1 or S2 has probably run into this: if you climb a wall up into a solid object, you can climb through said object. At some point you get ejected into the wall. What is going on is that there is a bug in the SolidObject routine that causes your position to not be updated when you hit such an object from underneath with either a zero speed or while going down. S3&K and KiS2 fix this, but in a different way than what I say here (with the S3&K/KiS2 way being also buggy). In fact, the way S3&K does it will kill y speed and inertia in cases where it should not, such as when you are on the air and going down, and clip the edge of a solid object — you will suddenly lose all downward speed. Here is how to fix it: Sonic 1 Open up "_inc/sub SolidObject.asm" and find this block: [68k]Solid_Below: tst.w obVelY(a1) ; is Sonic moving vertically? beq.s Solid_Squash ; if not, branch bpl.s Solid_TopBtmAir ; if moving downwards, branch tst.w d3 ; is Sonic above the object? bpl.s Solid_TopBtmAir ; if yes, branch sub.w d3,obY(a1) ; correct Sonic's position move.w #0,obVelY(a1) ; stop Sonic moving Solid_TopBtmAir: moveq #-1,d4 rts[/68k] Change it to this: [68k]Solid_Below: tst.w obVelY(a1) ; is Sonic moving vertically? beq.s Solid_Squash ; if not, branch bpl.s Solid_TopBtmAir ; if moving downwards, branch tst.w d3 ; is Sonic above the object? bpl.s Solid_TopBtmAir ; if yes, branch move.w #0,obVelY(a1) ; stop Sonic moving Solid_TopBtmAir: sub.w d3,obY(a1) ; correct Sonic's position moveq #-1,d4 rts[/68k] What this does is prevent you from going through the bottom of a solid object; so bug fixed. NEXT! Sonic 2 Find this block: [68k]loc_19B06: tst.w y_vel(a1) beq.s loc_19B28 bpl.s loc_19B1C tst.w d3 bpl.s loc_19B1C sub.w d3,y_pos(a1) move.w #0,y_vel(a1) loc_19B1C: move.w d6,d4 addi.b #($10-p1_standing_bit+p1_touch_bottom_bit),d4 bset d4,d6 ; This sets bits 2 (Sonic) or 3 (Tails) of high word of d6 moveq #-2,d4 rts[/68k] and change it to this: [68k]loc_19B06: tst.w y_vel(a1) beq.s loc_19B28 bpl.s loc_19B1C tst.w d3 bpl.s loc_19B1C move.w #0,y_vel(a1) loc_19B1C: sub.w d3,y_pos(a1) move.w d6,d4 addi.b #($10-p1_standing_bit+p1_touch_bottom_bit),d4 bset d4,d6 ; This sets bits 2 (Sonic) or 3 (Tails) of high word of d6 moveq #-2,d4 rts[/68k] What this does is prevent you from going through the bottom of a solid object; so bug fixed. NEXT! Sonic & Knuckles We will be undoing S3&K's buggy bugfix and doing it the right way. You want this code: [68k]loc_1E0E0: btst #1,$2A(a1) bne.s loc_1E0F6 tst.w $1A(a1) beq.s loc_1E126 bpl.s loc_1E10E tst.w d3 bpl.s loc_1E10E bra.s loc_1E0FC ; --------------------------------------------------------------------------- loc_1E0F6: move.w #0,$1C(a1) loc_1E0FC: tst.b (Reverse_gravity_flag).w beq.s loc_1E104 neg.w d3 loc_1E104: sub.w d3,$14(a1) move.w #0,$1A(a1) loc_1E10E: tst.b $37(a1) bpl.s loc_1E11A bset #5,$37(a1) loc_1E11A: move.w d6,d4 addi.b #$F,d4 bset d4,d6 moveq #-2,d4 rts[/68k] Issues with this code: (1) it clears your ground speed when you are on air and hit the bottom of an object (this causes Knuckles to lose all speed when gliding under an object, and nothing else); (2) it makes redundant a check in loc_1E126; (3) it clears your vertical speed when you are moving down and touch the bottom of a solid object (for example, by clipping the corner). We will fix all 3 by making it look like the versions for S1 and S2: [68k]loc_1E0E0: tst.w $1A(a1) beq.s loc_1E126 bpl.s loc_1E10E tst.w d3 bpl.s loc_1E10E move.w #0,$1A(a1) loc_1E10E: tst.b (Reverse_gravity_flag).w beq.s loc_1E104 neg.w d3 loc_1E104: sub.w d3,$14(a1) tst.b $37(a1) bpl.s loc_1E11A bset #5,$37(a1) loc_1E11A: move.w d6,d4 addi.b #$F,d4 bset d4,d6 moveq #-2,d4 rts[/68k] As far as I can tell, there are no ill effects of fixing (1), and (3) can cause some issues in random places. I discovered it because I had several portions of S3&K's solid object routine in SCH, and the rotating disc junction in SBZ1 fails when shooting you down with it. Now mind you, these fixes scratch the surface of everything that is wrong with these functions. You will still not be crushed while on the floor if you have any vertical speed, and you will still not be crushed if you are on air (or climbing) when an object pushes you into terrain from above. Fixing those requires a more extensive overhaul, and I intend to release SCH with those fixes before releasing the fixes to the public.
Coincidentally this also fixes those nasty collision clip issues on Sonic1/2 (really notably MZ chandeliers, though the edges have some quirkyness still). Awesome and simple fix!
It is not a coincidence, actually, but yeah, I guess I should have mentioned. The major issues of these solid routines are that (1) they don't care at all about terrain and (2) you can only collide with one edge of any given solid in any given frame. The game decides which edge you should collide with and ignores all others. With those chandeliers, they are moving down quickly. Without the fix I gave above, they simply go through you if you are on air and not moving up, until the game decides you are closer to the sides than the bottom. So you now collide with the sides, and get ejected out. With the fix, the chandelier will no longer go through you because you will be pushed down by it. At least, that is the theory. Depending on your exact position relative to the chandelier, when it moves it may still end up in a position where it decides you should collide with one of the edges and push you out anyway. But it becomes much rarer.
well I should have used other phrase I guess, I more meant "as a result". Either way this fixes lots of nasty clips you could do in my hack too, one of which skips a boss even, so its really nice to have it. Not to mention how easy it was just to stand against a wall and let the chandelier drop on you making these cuts really easy as long as your had a ring to spare. Of course the issue is cycles, the collision was made to be simple to not waste time, and as a result there are some particular issues like this. Luckily its a lot harder to notice too, so its not a big issue per se. Of course with enough speed you can practically break any collision on the game, but its not like its a problem with normal gameplay. Either way thanks for the fix!
The equivalent in the 2005 Hiverbrain disassembly is; loc_FBBC. Code (Text): loc_FBBC: tst.w $12(a1) beq.s loc_FBD6 bpl.s loc_FBD2 tst.w d3 bpl.s loc_FBD2 sub.w d3,$C(a1) move.w #0,$12(a1) ; stop Sonic moving loc_FBD2: moveq #-1,d4 rts EDIT: Inside the main "sonic1.asm" source file that is.
