Language…
13 users online:  Atari2.0, DanMario24YT, Dennsen86, derv82, drkrdnk, eltiolavara9, Fozymandias, Maw, Nayfal, prisvag, Red2010, Serena, steelsburg - Guests: 293 - Bots: 253
Users: 64,795 (2,375 active)
Latest user: mathew

Bug with "Sprites on Platforms/Springs" Patch

This patch: https://www.smwcentral.net/?p=section&a=details&id=16002

It's currently a known bug that when this patch is applied, certain interactions between Mario and specific platforms is bugged in a way such that while Mario is standing on them, he actually alternates between 'standing' and 'falling' every frame. Effectively, aside from being visually irritating, it also reduces the chance to jump off the platform to 50%, as you can only jump off while in a 'standing' frame.

List of sprites that are affected by this bug:
- Boo block (solid)
- Reznor platform
- There might be more that are undiscovered.

This bug already occurs when patching to a clean SMW ROM, SA-1 or not. As such it is not a compatibility issue (at most, one with LM, which is highly doubtful). leod, the creator of the patch, mentions he does not experience the bug when patching and actually remembers fixing this bug longer ago, but it's been too long to remember the details.

(My reference for the next part: Bank01.asm)

I've dug a little deeper and narrowed down the issue to the PlatformHijack at $01B457, the main portion of the patch:

Code
PlatformHijack:       ;the hijack most platforms with standard handling use, returns into ProcessInteract
JSL BeSolidToSprites

; restore SMW code
JSL $01A7DC
BCC .ReturnFar
RTL

  .ReturnFar
PLA : PLA : PLA
JML $01B4B2|!bank


The issue however is not caused by the JSL BeSolidToSprites, which handles all the custom sprite-platform interaction, but rather by the way the SMW code is restored. The hijack overwrites a JSR ProcessInteract (which is located at $01A7F7), and to compensate it adds JSL $01A7DC, which handles Mario-Sprite interaction. Technically, this routine does call ProcessInteract later on but also processes a few other things before that, which the original code at the hijacked address does not, though I'm not sure to what extent it matters.

And this is where I'm stuck. I can't see or think of anything in that part of the code that would cause this weird behavior. For testing purposes I tried to readjust the hijack in a way such that the original code would be restored one-to-one after calling BeSolidToSprites, but I haven't figured out a way yet.

Since this is an ingenious patch which I can see being used by a lot of people, I was hoping a solution to this problem could be found.
Well, while I haven't 'fixed' or figured out the cause of the bug, I did find a workaround for the affected sprites. Setting the sprites' Tweaker byte to "process interaction with player every frame" (fourth Tweaker byte, bit 5) will make the boo block and the Reznor platforms behave properly. Either modify those in the ROM directly or replace the original sprites with their respective disassemblies with GIEPY. It seems to work fine so far.
Originally posted by Ramon
The hijack overwrites a JSR ProcessInteract (which is located at $01A7F7), and to compensate it adds JSL $01A7DC, which handles Mario-Sprite interaction. Technically, this routine does call ProcessInteract later on but also processes a few other things before that

So what happens when you replace the JSL $01A7DC with an indirect jump to the ProcessInteract code?
As far as I'm concerned, a jump or JSL to ProcessInteract will mess it up because the routine will try to RTS out without being JSRed to, hence I haven't even tried it. Feel free to test it though; I won't be at my workstation for a couple more days.

If you didn't mean JML or JSL, then please clarify. I'm not especially well versed in assembly yet.