4 ms·

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:Supe

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.)

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.)