i would investigate the angle that XKeeper raised here:https://tcrf.net/Talk:Super_Mario_All-Stars
anyway, if you think it's related to Y_Speed, then set breakpoints in the two games' BrickShatter routines, followed by setting write breakpoints on Y_Speed to see divergences in how it's modified going forward.
also known as:
You probably should set a write breakpoint to Y speed
June 10, 2020, 03:05:32 am - (Auto Merged - Double Posts are not allowed before 7 days.)
1) in the main GameEngine routine (aka "CODE_03AD8F"), "JSR CODE_03C084" has been moved down a little from the original "jsr BlockObjMT_Updater". could be consequential, regardless of whether it's relevant to this issue, and it probably wasn't done lightly...
2) as far as trying to mimic the SMAS behavior in original SMB1: perhaps giving a larger negative Y Speed (e.g. FCh or F6h instead of FEh) in BrickShatter will overcome any version differences that hinder and then reverse upward velocity -- provided they're subtle enough -- and let the player continue upward momentarily?
if i'm right on #1 being the cause of this, the most direct way to achieve SMAS functionality would be to move that function downward, after the two "jsr BlockObjectsCore"s. you'd probably want to make sure that there were no side effects (e.g. variables BlockObjMT_Updater alters that BlockObjectsCore or its callers read from), or at least none in excess of what SMAS has.
if you're looking to be less invasive to current NES functionality (yet have more additional code and free space usage), i think that introducing a custom variable would be the best route:
- mark a Brick_was_smashed_last_interval in the BrickShatter routine, and clear it on regular intervals. if NYSpd detects this variable is set, clear it, and abstain from setting Y Speed to 1. so you're creating a loophole in behavior. ideally, you'd verify that Mario's head is still at/in the broken brick before branching, so as to limit the size of the loophole, but i dunno how to do this.
- have BlockObjectsCore (and maybe BrickShatter) instead set a Prepare_to_Set_Block_RepFlag , which BlockObjMT_Updater would then detect, clear, and if it was set, mark the actual Block_RepFlag and proceed as normal. it'll then be handled on the NEXT call to the function. the downside is that with this being an indexed variable, you'd need to create a custom one for each possible block, consuming a fair amount of RAM space. unless
you take advantage of the fact that Block_RepFlag is currently just 0 or 1, rework all existing modifications to operate on only Bit 0, and then claim one of the other bits for your custom flag.
anyway, it's worth verifying whether the reordering in GameEngine / CODE_03AD8F discussed in #1 is actually responsible for the brick physics difference before pursuing any of this.