4 ms·

It feels different because of a one-bit screwup! https://www.romhacking.net/hacks/167/ https://www.romhacking.net/hacks/167/

Tarsul 5y ago
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!
- Wowfunhappy 5y ago
  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.
nyanpasu64 5y ago
I heard that this "one-bit screwup" theory is incorrect: https://tcrf.net/Talk:Super_Mario_All-Stars#SMB1.2FLost_Levels_Brick_Physics 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.
- Wowfunhappy 5y ago
  Huh, yeah, I'd really like more detail on that. Google isn't turning up anything. Having used the patch, it does feel right...
- derefr 5y ago
  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.)

Tarsul 5y ago

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!

Wowfunhappy 5y ago
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.

nyanpasu64 5y ago

I heard that this "one-bit screwup" theory is incorrect: https://tcrf.net/Talk:Super_Mario_All-Stars#SMB1.2FLost_Levels_Brick_Physics 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.

Wowfunhappy 5y ago
Huh, yeah, I'd really like more detail on that. Google isn't turning up anything. Having used the patch, it does feel right...
derefr 5y ago
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.)