that video on mario 64 invisible walls is incredibly impressive but also I feel like the sheer amount of "for some reason"s and "this game is soooo glitchy and buggy" comments in the video are going to do a lot of work disguising the fact that every single one of these optimizations are probably the only reason ANY of that shit runs on the n64 hardware to begin with
experienced gamedevs didn't take these shortcuts for fun, they likely were under signifiant time pressure, under a shifting technical landscape, and trying to optimize for complex collision on a processor whose clock speed is significantly outdone by any post-2007 graphing calculator
the fact that by and large ONLY speedrunners see these issues is frankly a real testament to how well they did
I particularly want to call out the final topic of the video, which is that ground height-sorting in mario 64 is handled by comparing the height of each object's first vertex (in order, which is arbitrary) - which means that in some cases objects can be sorted lower than they should be due to ties or awkward first-vert placement.
I 1000% guarantee you this was a late-in-development optimization addition. They were almost certainly doing some sort of more complex detection and it was eating up too much frame time and so they redesigned it with the two principles that cause the bug in question, which is:
- only compare two vertices' world locations, total, a single math operation
- then abort as soon as the check is successful and don't check any other collision anymore
This smells very strongly of frantic optimization. "what platform is below mario" is a check that has to run every frame and it's almost certain that on maps like Tick Tock Clock there are situations where probably 7-10 possible valid ground planes can be underneath mario at any given time. During dev, not knowing the N64's final specs, you set it up to just be a thorough check that compares every possible landing spot, and suddenly you're a month from release and the game needs to ship in time to be a launch title and mario's ground collision check is taking like 400 ms, your manager is like "just make it run! we'll test for any bugs where the vertices cause weird collision" so you do that and you catch and adjust for anything you notice, and the minor remaining ones get left out.
It's extremely telling, IMO, that ALL the places this bug is an issue are minor props and weird unusual collision cases that are very hard to notice in normal play. There were probably way more at first and then they went through and fixed every reported one by hand. "why didn't they just build a tool" you might think, but they were almost certainly working under significant time constraints and sometimes you just say "good enough" and throw testers at it and then move on to the next bug and the next optimization. This is quintessential game development, and not a bit of it lazy. Shit's hard and time is a real thing.
Sebastian Lague's latest video on font rendering covers his development process for this sort of thing really nicely. It's not so much about performance optimisations but it's a good view into why the naïve approach to algorithms often won't work and how edge cases are hard to spot.
I honestly love this sort of thing, it's really interesting to see how developers approach problems, and then what edge cases those implementations cause. Especially when these edge cases are because of hardware limitations or data type choices (the different types of imprecision you get from integers and floats especially)
This is basically exactly the sentiment I was going to express