I'd be curious to know more about the development of Super Mario All-Stars. I've been playing both the original and All-Stars (on the Switch--if that matters) and the acceleration of Mario in SMB1 feels different. The original SMB and All-Stars were only released 8 years apart. If they didn't use the original code base they likely had access to the original dev team.

It feels different because of a one-bit screwup!

https://www.romhacking.net/hacks/167/

I heard that this "one-bit screwup" theory is incorrect: https://tcrf.net/Talk:Super_Mario_All-Stars#SMB1.2FLost_Leve...

> The actual mechanics behind the issue were discovered a while ago (the Y-reverse thing isn't right). Something to do with the block getting replaced immediately instead of a one-frame queue/delay.

Unfortunately I can't find a fuller explanation for this claim.

I wonder if this isn't a bug in the SMAS remake, but rather in the original game.

Maybe brick-blocks taking an extra frame to swap from tiles to sprites for their animations, was something perceived as an unfixed bug (or a necessary compromise, due to per-frame CPU-time limits) at the time of the original's development — one with, perhaps, a "TODO" comment sitting there in the original assembly source. And the development team of the port noticed that, with either more dev time, or with the increased cycles-per-frame available on the SNES, the "bug" was able to be "fixed".

But perhaps — since that team wasn't aware that the change in physics this created was unexpected by the original devs — they thought that the physics resulting from "fixing" this "bug" were the originally-intended physics of the game (i.e. that the animation "bug" was a regression, and fixing it put the game back the way it was in some earlier build), rather than that they were introducing a regression themselves.

These sorts of things are the reason I've always wished version control got used more heavily in the gamedev industry back in the 80s. Then any leak of a game's code-base would actually have a productive use (rather than just serving as poison fruit to aspiring developers): it could be a treasure-trove of data for Software Engineering academics to study the in-industry SwEng practices that lead to "good" games vs "bad" ones.

(I've had a longstanding hypothesis that many "bad" games from the 80s/90s were "good" games for much of their development, but got broken very close to release as they tried to merge in tons of longstanding feature-branches — i.e. the exact problem Continuous Integration tries to address.)

Huh, yeah, I'd really like more detail on that. Google isn't turning up anything.

Having used the patch, it does feel right...

your link is about the behavior when Mario hits a brick whereas OP was talking about acceleration of Mario (I think he means running?!). Quite interesting link, nonetheless!

Yes, but we often don't feel what we think we're feeling! The patch changes Mario's speed when he hits a brick, which will have implications for when he hits the ground.

I'm far from an expert player, but I really think the physics are identical once the patch is in place. I sometimes wonder if it was really a mistake at the factory—something they didn't catch until 20,000 PCB's in, and didn't want to change in revisions for consistency.

They did use the original source, the All Stars source is included in the recent leaks of Nintendo software.. You can see a lot of the original code and see what they changed. It seemed when I glanced at it that the SNES developers used a different level of indentation so it was noticeable when some new code was added in.

Are you from a PAL region? It sounds your issue may be due to playing an NTSC 60Hz version vs a PAL 50Hz version