$8655 is only triggered when Simon is falling and hits a (semi-)solid object, so it won't run on most frames.
That's when I'd do the y-pos test which from small testing, I don't think it would affect the fall through floors bug, but I am curious why that happens also.
I might try writing a proof-test to see how well it works later. You pulled off some incredible technical feats with this game; I never realized still how slow the engine is running. That's a bummer. :|
Explanation of floor bug:
- Walk off floor and use item. ObjectXSpeed = 1. ObjectCurrentActionType = 5.
Note that ObjectXSpeed = 5 when normally falling straight down and using item.
- If the subpixel height gain from using item is large enough, we get a pixel shift.
Which causes us to miss the floor detection on next frame.
- When item is done playing, $DC86 is called to reset pose.
Because ObjectXSpeed = 1, game thinks we are walking sideways (not falling).
Turns off Temp93.
- Simon is allowed to free-fall for at least 1 frame because _loc_C632 is not doing collision detection.
- Sometimes game turns back on Temp93 and Simon keeps falling to next platform below.
Other times Temp93 is off and dies below.
Not sure if there's another way than to insert kludge at $DC86 to check for ObjectCurrentActionType(05) and turn back on Temp93. :|
But $DC86 runs only 1 frame of lag since it's putting the item away.
Or it can be done here?
$86E0 A9 01: lda #$01
$86E2 20 C0 D3: jsr CheckIfBoneHeld_SetSimonAutomaticSprite_To_Table_Atimes2plusBone
$86E5 20 7A 87: jsr Clear_Unknown6Cand6D
$86E8 A9 05: lda #$05
$86EA 4C BD DE: jmp Object_SetCurrentActionType_For_Simon
It's a 1-time tiny hit for walking off ledges and works to solve the glitch. Although dealing with free space looks annoying.
I have a naive question about this snippet.
$86ED 84 94: sty Temp94
$86EF A9 FA: lda #$FA
$86F1 A4 94: ldy Temp94
$86F3 20 AC D3: jsr Simon_CheckMapCollision
$86F6 85 04: sta $04
$86F8 A9 06: lda #$06
$86FA A4 94: ldy Temp94
$86FC 4C AC D3: jmp Simon_CheckMapCollision
Based on the xspeed, couldn't you just check 1 side or the other? Seems like a waste to check both sides of the map if you're heading in one exclusive direction.
I can imagine that if we reduce the range that Simon’s Y-coordinate is automatically aligned to the nearest surface
My safety net was to see the previous oam or physically drawn y-coord on-screen.
Normally when falling down, Simon's last visible frame should always above the platform. In the 3-pillar exploit, he's clearly seen below ground and on a descending
velocity; last oam value useful to detect this.