To be fair, game devs did the hackiest shit to deal with the constraints of the time. They did things that no programmer would do today because they’re bad practices when you’re not worried about tiny amounts of RAM or storage.
I love watching videos about old game systems programming. The gymnastics you had to do to code, like, super Mario, just to show more than 3 colors is really interesting.
People who think modern coding practices are bloated should study why certain speed running mechanics work. A lot of them stem from things we would never do today. We’ve removed entire classes of bugs by using “bloated” languages and tools.
But we introduce entirely new classes at the same time.
A Cuphead dev reacting to Cuphead speedruns is an interesting watch because he explains why all the tricks work.
You will probably enjoy this video: https://redirect.invidious.io/watch?v=nYDmBdUalgo
Dude livestreamed Super Mario 64 for more than a month with a bot attached that perfectly abused a physics quirk based on floating point precision, just so he can crash the game at 0:00 at New Year’s by overflowing a value. This over-one-hour-long video is the summary.
The games then were closer to embedded dev than software dev. The cartridge had huge limitations and the devs had to know those limits and work around them.
Cartridges were also full on daughter boards instead of just an older version of SD cards. There were massive differences between games. The later SNES games with 3d graphics had a whole extra processor included in the cart.
The old Super FX chip. I’m old enough to remember when they released the original Star Fox and flogged the super onboard 3d processing. The ads in comic books mentioned it by name.
Sometimes they did it just in case they needed those limited resources, but its not really needed. SMW is a good example, where spite interactions are only checked every other frame, but modders generally remove that limitation without any issues. There might be weird edge cases where in vanilla without glitches you could theoretically accumulate enough sprite on stream it causes a slightly more noticeable slowdown without the ever other frame. With cape float, it only checks if you are holding the jump button once every 4 frames or something like that. Totally unnecessary and makes the game feel less responsive. Granted, during a casual playthrough, you’d probably never notice that floating stopping after letting go of the button varies by 50ms depending on which frame you let go of the button relative to which frame it checks.
And even then the code was far from the best it could be.
This guy optimized Super Mario 64 and drastically improved performance while fixing several bugs.
