Edit: An user in the discord pointed me that the previous changes break some collisions. An extra check is necessary to avoid this, but instead of increasing the processing, a table will be used to increase the speed. "The 45 to 0 degree bug". Why can´t CPz have loops with slanted corners (You can't go from 45 to 0 degrees)? Did you noticed that if you try to walk in the right side of the slanted corner the collision will behave wonk. Why this occur? Goto to routine Sonic_Angle and look in the code of loc_1E380: Code (Text): loc_1E380: move.b angle(a0),d2 addi.b #$20,d2 andi.b #$C0,d2 move.b d2,angle(a0) rts The issue is caused by the line "addi.b #$20,d2". If you are at 135 degree the value in D2 is $E0 and adding $20 will result in 0, but if you are at 45 degree the D2 have the value $20 and adding $20 will result in $40, that are incorrect. How to fix? replace the code after loc_1E380: with this Code (Text): loc_1E380: moveq #$00, D2 move.b Obj_Angle(A0), D2 move.b Next_Angle_Table_Data(PC, D2), Obj_Angle(A0) rts ;------------------------------------------------------------------------------- Next_Angle_Table_Data: dc.b $00, $00, $00, $00, $00, $00, $00, $00 dc.b $00, $00, $00, $00, $00, $00, $00, $00 dc.b $00, $00, $00, $00, $00, $00, $00, $00 dc.b $00, $00, $00, $00, $00, $00, $00, $00 dc.b $00, $40, $40, $40, $40, $40, $40, $40 dc.b $40, $40, $40, $40, $40, $40, $40, $40 dc.b $40, $40, $40, $40, $40, $40, $40, $40 dc.b $40, $40, $40, $40, $40, $40, $40, $40 dc.b $40, $40, $40, $40, $40, $40, $40, $40 dc.b $40, $40, $40, $40, $40, $40, $40, $40 dc.b $40, $40, $40, $40, $40, $40, $40, $40 dc.b $40, $40, $40, $40, $40, $40, $40, $40 dc.b $80, $80, $80, $80, $80, $80, $80, $80 dc.b $80, $80, $80, $80, $80, $80, $80, $80 dc.b $80, $80, $80, $80, $80, $80, $80, $80 dc.b $80, $80, $80, $80, $80, $80, $80, $80 dc.b $80, $80, $80, $80, $80, $80, $80, $80 dc.b $80, $80, $80, $80, $80, $80, $80, $80 dc.b $80, $80, $80, $80, $80, $80, $80, $80 dc.b $80, $80, $80, $80, $80, $80, $80, $80 dc.b $80, $C0, $C0, $C0, $C0, $C0, $C0, $C0 dc.b $C0, $C0, $C0, $C0, $C0, $C0, $C0, $C0 dc.b $C0, $C0, $C0, $C0, $C0, $C0, $C0, $C0 dc.b $C0, $C0, $C0, $C0, $C0, $C0, $C0, $C0 dc.b $C0, $C0, $C0, $C0, $C0, $C0, $C0, $C0 dc.b $C0, $C0, $C0, $C0, $C0, $C0, $C0, $C0 dc.b $C0, $C0, $C0, $C0, $C0, $C0, $C0, $C0 dc.b $C0, $C0, $C0, $C0, $C0, $C0, $C0, $C0 dc.b $00, $00, $00, $00, $00, $00, $00, $00 dc.b $00, $00, $00, $00, $00, $00, $00, $00 dc.b $00, $00, $00, $00, $00, $00, $00, $00 dc.b $00, $00, $00, $00, $00, $00, $00, $00 ;------------------------------------------------------------------------------- Build and now you can have slopes with 45 to 0 degree in both directions. And if you are using Sonic and Knuckles like Sonic Delta 40, the code is at $ED7A
There is a possible slight oversight with how the push sensor is positioned. I wrote about it for Sonic 1 here. I will add that Tails in general is more suspect to this oversight, because his natural and rolling hitbox heights are almost the same, and thus the threshold for him is always quite low. In s2.asm, go to loc_1EBE6, and add this right under addq.w #8,d2: Code (Text): btst #2,status(a0) ; Is the Player rolling? bne.s + ; If not, branch cmpi.b #ObjID_Tails,id(a0) ; Is this Tails? bne.s ++ ; If not, branch addq.w #1,d2 ; Offset push sensor movement when not rolling + subq.w #5,d2 ; Move the push sensor up Then, change the "+" in this to a "++": Code (Text): andi.b #$38,d1 bne.s + And you'll get this: You can adjust the numbers to your liking if you please. I will also note that if you make it so that the push sensor is enabled for other directions (like S3K does when running straight up/down on a wall or running on a flat ceiling), then modifications to account for that will need to be made.
I haven't had a chance to try this, but from what you describe, this sounds like the reason they may have changed the loops. Nice to know you have a fix for it though. 20+ years later, you're still posting interesting stuff!
A sharp eye while observing the behavior of some badniks in frame advance mode revealed two that are not setting their display width correctly: the Turtloid and the Grabber's head/body. The Turtloid's sprite is $38 pixels across, but the width is set as if it's only $30 pixels wide, causing it to pop in abruptly at the right of the screen: Code (ASM): ; Sonic 2 Git Obj9A_SubObjData: subObjData Obj9A_Obj98_MapUnc_37B62,make_art_tile(ArtTile_ArtNem_Turtloid,0,0),4,5,$18,0 ; that $18 should be $1C! ; =========================================================================== ; Sonic 2 Orion SubData_Turt: subobjdata Map_Turt,tile_Nem_Turtloid,render_rel,5,$30/2,id_col_null ; that $30 should be $38! Likewise, the Grabber's widest sprite is $2C pixels wide, but the width is set as if it's $20, causing it to both pop in and disappear prematurely at the edges of the screen: Code (ASM): ; Sonic 2 Git ObjA7_SubObjData: subObjData ObjA7_ObjA8_ObjA9_Obj98_MapUnc_3921A,make_art_tile(ArtTile_ArtNem_Grabber,1,1),4,4,$10,$B ; that $10 should be $16! ; =========================================================================== ; Sonic 2 Orion SubData_Grabber: subobjdata Map_Grab,tile_Nem_Grabber+tile_pal2+tile_hi,render_rel,4,$20/2,id_col_8x8 ; that $20 should be $2C! Changing the width values to the ones noted above fixes both of these bugs, however small they may be.
An user in Discord pointed me that the 45 to 0 degree fix break some collisions, the original post (https://forums.sonicretro.org/index...-fixes-for-sonic-2.29029/page-33#post-1048893) with the fix was edited
