Since people keep suggesting to just put a death barrier under levels, here are 4 reasons why that's a bad idea: 1) You can now fall through the level into the death barrier when there would be holes. 2) Those holes are harder to detect and will be less likely to be caught before release. 3) Slanted walls/floors with vanilla physics can be clipped through pretty easily - the death barrier under the level would make this a lot easier and players would end up clipping into the level all the time. 4) It's more triangles = more RAM = less vroom vroom
@@dazcarrr its 1 extra nodes per cell and 1 extra iteration per cell. probably like 4us of data throughput more in an average frame and 32kb of extra data used
How does adding a death plane make clipping easier? Is it because there's no longer OoB walls holding you back after you've worked your way through a slope?
Btw I think 3 is the only real concern here, 1 and 2 can both be solved by fixing geometry before applying the death barrier (or the simple fact that most seams are hard to fall into unintentionally), and the death plane is 2 more triangles at most which with modern hardware is a laughable amount of process power lost and certainly more than handlable for an N64. Preventing all invisible walls in 5 minutes at the slight cost of speed and with some seams remaining is more than reasonable as a tradeoff versus spending hours of your life debugging and fixing geometry.
@@Edamori sure but why take a patchwork fix when you can apply a very real fix like i describe in the video. If you've ever played sm64 x banjo tooie (the one made in 2015ish?) and beat glitter gultch mine you'll see why a patchwork fix is not good enough unfortunately
I was thinking of exactly this after the Pannen video. Then again, I've seen Simpleflips die to nothing enough times to know that invisible walls at the very least exist in some older ROMhacks.
yeah if anything they are more common in romhacks - because romhacks typically have more complex geometry and don't align all their stuff to world axis.
Yeah, making an invisible wall free version of Mario 64 would be great, but y'know what would be better? Chaos Mario 64: Bonk Edition where practically every vertex in the game is misaligned just enough to make small 1-unit wide invisible walls EVERYWHERE. That would be a monumental task though.
It could be an effect of Mario 64 Chaos Edition to randomly set Mario to the hard bonking animation state. No need to change any collision :) It would be even funnier, since then he could randomly bonk on nothing while standing completely still, or completely ruin a jump by bonking midair. For bonus points, if Mario was on the ground as the effect triggered, set his Y speed to be positive so he gets some airtime from the earth-bonk.
according to sm64 logic, the leaning tower of Pisa might be home to the largest and most famous invisible wall, as the wall that leans in doesn't stop the out of bounds hitbox from leaking through (spelling error, logic error check in progress)
No, it leans far enough for the wall to actually be a ceiling. However, there are tons of little details that would let ceilings leak through even if it wasn't leaning
pannen showed the to scale leaning a wall can have before becoming a floor and it’s pretty fuckin slight so as much as I’d LOVE to see someone bonk above the leaning tower I think that one’s safe.. but are its vertices aligned?
@@redtaileddolphin1875 just remembered that, gotta reword that considering it's circular/tube like shape, the walls would probably be on 2 of the sides, not the exposed lean-in side of the wall. unless the scale of wall and floor angles were increased for that wall to qualify as a wall surface
This is false. According to this logic, invisible walls wouldn't be produced in real life, because you can't have missing geometry in real life. Any ceiling necessarily also has a floor on the other side
@@BigBinky3000yeah I wonder why he doesn’t release it. Maybe he just wants to get paid for all of his work doing that, not just give it away for free online.
As a hack creator, this is way more annoying for the creator to have invisivle wall in his level than for people who play it, the slopes invisible wall is the worst one definitly
I know I'm a huge nerd for pointing this out but the vertices aren't rounded, they're truncated. Rounding would set the value to the nearest whole number, but instead they convert it to an integer by just discarding everything after the decimal point. This means the vertice would always be set to the next-lowest coordinate value; for instance, 12.9 and 12.1 would both be converted to 12.
Semantics, though. You have a narrow conception of the word "rounding", but a broader conception could include truncation as a type of rounding. Go to the Wikipedia article "Rounding" and then scroll down to the section "Rounding to integer". They literally have a table at the bottom of the section showing many different ways you can round to an integer (including toward 0).
It’s amazing the programmers decided it would be better to work around these bugs rather than fix them. Especially the floor overshadowing; imagine how many times the level designers had to reorder vertices to prevent the same bug over and over without ever realizing their job could be so much easier!
@@KazeN64 i have to disagree, rounded corners hold you back on crossovers, all while not giving you any feedback cue for what is happening, making them worse than vanilla imo
ah, i thought we were worried about invis walls only there. yeah i imagine getting rounded on those corners is not a great experience in kaizo hacks like that
@@galoomba5559 That works for glitchy bonks, but there can also be other stuff like indefinitely getting pushed to stay in the corner, and if the floor extends further out than the wall you end up with a deathpixel or at least an edge that will give you a false sense of security for crossovers
It wouldn't be possible for a mod, because you'd need to raycast on every unit of the map to discover where they are, which is far beyond the N64's capabilities. Perhaps with an emulation tool, which is how I assume Pannen did it, though who knows if it even runs in real time.
I just remembered, that there is a tool called STROOP that Pannenkoek and many other members worked on to show almost any information about sm64. I think it can show them, and it might be what is used in the video as well. Not sure about real-time though, haven't looked too much into STROOP.
I wonder if at some point in development they planned Doom-like no-slopes geometry, because none of the errors would crop up with only perfect vertical walls.
and by the time they'd abandoned that idea, the code was already written. granted, it'd have to have been pretty early in development, perhaps at the very beginning, since even the earliest beta levels discovered have slopes. but who knows?
@@videopsybeam7220 could also be they just wrote the majority of the code for a very alpha "here's a floor and some boxes" test environment... then never updated it.
Mario 64 was a mess of a development. Parallel teams contradicting each other, rushed dev, cut content at the last moment, an incomplete hardware design, a new method of game design that the team was unaware of how to implement, and Miyamoto in his most tyrannical. The game's code is a mess, a big giant mess held together by code duct tape and luck
2:56 Glad finally to get an explanation of this at the source code level. Just another one to file under S for "somebody please get me some of whatever those developers were on." EDIT: It later became apparent to me that the goal here might have been to stop Mario clipping inside of entities, ("objects" with "dynamic surfaces," in the game's parlance) like boxes or thwomps, and certain kinds of geometry from below, so it looks like we can refile this under F for "friends don't let friends perform_air_quarter_step."
To make an invisible wall visualiser like pannen, just rasterize the level top down, at slightly more than the integer precision of vertex, then for each polygon keep track of facing in the rasterize pixel, track the depth span of each wall line at each top down pixel, then draw the vertical span in a regular rendering, to visualize them.
you will have to do this at various heights as some invisible walls are not infinitely tall (and this only finds issues in level geometry, not those caused by objects, unless you want to make a raster view for every possible configuration of objects and heights)
@@MagicGonads you just rasterize top down back to front, and put a per pixel list of state with depth value, then for each list, you remove data that cancel itself...
@@MagicGonadsseeing as an object collision only exists when you are close enough, and almost always will be triggered by the objects own ceiling you can just cast rays from the objects ceiling straight up that stop when they hit a floor triangle.
This is something I never considered until that video last week. Imagine how many romhacks inadvertently add invisible walls without realizing it. The whole invisible wall thing has shifted my view of the game and has made me somewhat paranoid. They can be practically anywhere.
Will you ever make a "deluxe" version of SM64 where you implement all the quality of life improvements that is known to you? Can't wait for the release of your game!
It does sound like a massive improvement to have 1 unit holes in the ground instead of 1 unit columns of inviswall, especially because it seems like a lot of those holes would be in an unreachable spot right next to a wall.
@@LocalAitchwell I feel like players accidentally clipping out of bounds by landing or walking in the wrong spot is less bad than having their entire gameplay experience interrupted by an infinitely tall invisible wall thats seemingly there for no reason, so it would still be an improvement
To manually fix 'holes' in levels with the death barrier, you could remove the death barrier and now check for OOB invisible walls, then put the death barrier back. You still can't find ordinary holes (that just go down to a lower floor that isn't the death barrier), but at least you won't fall out of the level.
I love how at least once every video they say something along the lines of "So this single change I made makes the game work properly and its performance is better". You could make a drinking game out of it
LMAO i wanna make sure people don't comment something like "okay but now its more performative so that's probably why this bug existed" - because i've gotten so many comments like that about simple changes before.
Please don’t ever stop schooling us about Mario 64. This game holds such a huge space in my heart. Love learning new things from someone that has dedicated so much of their time to it.
@@AlexanTheMan It's not. Developers actually took the time to patch bugs and improve quality of life. It's weird no one has patched the invisible walls yet.
@@Accrovideogames That highly depends on what kind of build you got, I'm pretty sure the first one was just put out there with little to no maintenance only to be quickly struck down by Nintendo.
We need all the modding bros to collaborate on a perfect version of SM64. Where all it does is fix all of the code and gets the game running locked 60 on actual hardware. It would be epic.
I was waiting for this video. I hope that one day either you or someone else compiles all your optimizations, while also correcting any floor gaps, to make a bug fixed version complete for Mario 64.
The port of all of the improvement-changes to the base game will be legendary, when it happens. Until then, Kaze will continue making the romhack the changes were made for absolutely cracked. It absolutely approaches the territory where one could be fooled for it being an early GC game.
I was hoping you would respond to Pannenkoek's documentary. I knew you already knew about the problem, its causes, and had clever solutions for them in your mods. Thank you for your hard work!
I'm surprised to hear that there isn't a standardized tool for the modding community to use of a visual debugger like in the pannenkoek video that makes it super obvious where the invisible walls are. Does that exist already? Is something like that feasible?
Actually calculate the coordinates and integer values. N64 is pretty weak nowadays so they had to round the values to save processing power and RAM. You don't want everything to be calculated and lag, so they rounded or 'Truncated' the values, taking the numbers after the decimals (1.1, 1.9) leaving the whole number (1, 1) and apply the collision there. This leaves gaps if things are at an angle and not whole, like 9.2, or 8.4, as collision is only on the 9 or 8, leaving gaps for out of bounds to leak through or ceiling to leak through. Good optimization, but requires some fixing to make things work properly, as Kaze showed us (Moving the floor under the objects, and cutting the ceiling early.)
Even if the vertex itself is rounded, it won't fix the problem because diagonal edges exist, and diagonal edges don't always line up with the rounded positions.
If you wanted to be mathematically consistent, you should either round to nearest (ties to even), or always round down. Rounding to 0 is almost completely useless, which is why it's the default in C resulting in Mario 64 using it.
A hidden gift from this video is helping people empathize with how easy it is to miss these things. It's kind of hard to watch Pancake's video and not think the devs were just a little too careless / sloppy. Watching 8:01 is like "ok, yeah, that looks like it sucks."
A guy named *Marc ten Bosch* wrote an article about removing quaternions from 3D engines, by reimaging all rotations as happing in a plane rather than around an axis. It's worth a read, check it out when you have the chance! He also wrote a 4D physics engine (as in four spatial dimensions, not 3D plus time), if you're curious.
I think another way to solve the issue would be to apply wall logics as a result of the 1/4 steps function only when 2 consecutive such test give the same output. Since most invisible wall are thin, they should only detect a collision on 1 while actual wall are thick would still be detected accurately the vast majority of the time. Also since this logic will always be loaded and CPU is not the bottleneck, maybe it would even be possible to double the test to 1/8 steps so that effect can still apply at the same 1/4 steps despite the fact wall logic would be waiting for 2 positive collision detection. Of course I think your solutions is better, I'm just thinking of a solution that would result in a minimalistic change vs the original source.
The reason they did it this way is, simply, it was the first 3D platforming engine they made, one of the first made anywhere. Roughly contemporaneous with the original Tomb Raider, which has much simpler geometry. It's kind of crazy that Mario 64's areas are so complex, it looks like they took an "art first" approach, where Mario should just be able to navigate arbitrary terrains. The result was a bit janky, but ultimately successful, I think history has vindicated their approach, it formed the foundation of an engine that would be used over and over through the N64 era, and they got much better at doing 3D platforming engines in later iterations.
If you can just get a script that checks the map for small invisible walls and tells you where they are you can move the vertexes a unit or two until the wall goes away then the problem is solved.
I remember the old days (around 2010) when we didn't even know why it happened, it all seemed random. Making invisible wall-free maps in sketchup was a nightmare
I was hoping to get your opinion after watching that nearly 4 hour long documentary! I think it would be cool if you made a Mario 64: Kaze edition that fixes everything in the way you do it while adding all of your optimizations and optional enhancements like the added lighting effects and extra move set. That would be amazing!
4:37 Mario sunshine has this same collision issue. We noticed nintendo put a really big polygon under the map to solve any potential invisible walls caused by level bounds. why would you generate a lip of geometry inside of the wall or is N64 just that weak that it can't handle large scaled collission triangles 🤔
Every time I watch one of your videos, Kaze, I just want to go model M64 levels or something. You have an inspiring vibe, my man. Thanks for the content, as always.
I mean, out of bounds invis walls are the easiest to deal with, just put a deathfloor in the level (and if you want to emulate the oob level boundaries, just slap big untextured walls on the level). It's a hack, but it works. Ceilings are harder to deal with due to the inherent problems with the jankass collision system, the best solution is obviously to rewrite it but barring that... follow strict technical guidelines when designing your levels, avoiding split edges wherever possible (even at the cost of making a mesh more dense) and when not possible you have to take care to intentionally cause overhangs rather than underhangs. It's... workable, it's still better to fix the underlying problem though by either changing how collision works as such: 1) patch OOB blocking and killing mario, encase levels in invisible walls and put a deathfloor at the bottom [even when not normally reachable] 2) make ceiling hitboxes not be infinitely tall (ideally change collision to work like it does in the majority of games actually) and/or change to at least fixed point precision coordinates instead of integer coordinates, though the N64 actually has hardware support for fast floating point operations so there's not that much reason to not just go for it. It's a bit slower but such is life. Anyway, fixed point precision maths combined with the technical modeling restrictions mentioned can ensure that there is no 'leaking'. This is a pain in the arse, just fix it properly instead.
For a specific map this could be solved like an integrational tests do: make raycast from each point of inner volume with collision checks run over the Ray’s hits. With such simple geometry on modern hardware it should be quick enough.
Thank you for condensing this down into ten minutes. I started watching that video without realizing it was FOUR HOURS LONG JESUS CHRIST. Props to that guy for being thorough, but goddamn.
a 'stupid' solution to the oob invis walls would be to add a death plane to every world regardless if you're meant to reach it or not. but that would be treating the symptom and not the cause. someday, I would like to see a fixed and optimized sm64 running on intended hardware.
I still wish that the subscribe button from your outro was a series of [!] floor buttons that looked like a single long rectangular button and had the subscribe text on top, and maybe their origin sits below the map, so when Mario runs through them and presses them, it reveals the "subscribed" gray button as a map texture. Finally, the last button gives Mario the star.
the reason they made ceiling hitboxes go up until it hits a floor is so you cant clip inside thwomps as they squish you at high speed. with your patch it will be surprisingly easy to clip through the few in the game with a well-timed jump as the thwomp's ceiling hitbox combined with mario jump will move through mario fast enough to get through it within a frame and then mario has all these weird hitbox interactions within the thwomp like walls and floor on its top that will let mario escape unscathed. Their implementation stops mario from moving into the thwomp if the speed is too high and sticks him in place. they wanted squish mechanics to be "fool proof" its also why they have priority over other hitboxes too.
They are 500 coordinates in size. Their max vel is 75. Marios max vel is about 80. You cant even get 1/3rd through them. And if you could, the bug would be the same with and without the changes
@@KazeN64 is "they" (500 coordinates) your new ceiling hotbox or the thwomps? it sounds like it's the thwomps from your reasoning that the bug would exist in either case but you don't need to go through the entire thwomp if the ceiling doesn't go up until it reaches a floor like your patch.
Even if this did break the Thwomps, one could just tweak them instead. There is no good reason to just make ceilings "infinite until stopped" across the board.
Yes it does seem possible that checking from the floor height to the ceiling may have had something to do with preventing Mario from clipping into a box or something similar (not just thwomps) from below, now that I think of it. Remember, though, that Kaze's changes include chucking the whole mad quarter_step scheme and just validating each move all at once by searching for any surface between the old and new positions. If Mario would have passed through the ceiling on the the thwomp's underside, he won't clip inside under this system, no matter _how_ fast he or the thwomp is moving.
I always love all of your videos, even cooler to see your video after Pannenkoek's one! I have one question: I'm pretty ignorant, so I'm probably missing something, but doesn't removing quarter steps make you also need 1/4 of the speed to clip through walls? Like, the sliding speed you get on slides of 100 should be enough to clip through a wall, considering you normally need less than 400 speed to do so. Maybe I'm missing something though
usually yes - but i use the move validation to raycast from mario's old position to his new one to check if it passed through any geometry. that way i can just snap mario back and check if a move there is valid. that prevents all movement through walls.
You don't need to check 4 discrete positions for wall collisions when you can just do what most games do and check the entire continuous path instead. This is what ray-casting is for.
If we ever get to see time machines in our lifetime, I see you going back to 1995/1996 and work with Nintendo to release a polished version of Super Mario 64.
surely a good way to circumvent the out of bounds invisible walls would be to just add a death barrier even when one is not needed. And if you use out of bounds as the border of your level, just have the out of bounds floor be a silhouette of the stage. Sure extra polygons aren't great, but i feel it wouldn't impact performance much
Thank you for the trunkated version Pannen's video. I'm about 3 hours into rhe video and still have an hour to go. I will still watch it to its end. Just I think it's good to have a shorter version out there for people who just want to gwt the gist of it.
If vertex placement and alignment are important, avoid Merge By Distance because it averages the vertex positions. Instead use Merge At Last with the last vertex selected being the one at a correct position.
1:59 So what would happen if the collision vertices were not rounded/truncated? Would this completely eliminate the misaligned edges? Could this be a practical solution?
yknow, i wonder how much would be fixed by just, like, making ceilings not go on forever, and by making Out of Bounds some kind of specifically-set thing or whatever
I'd love a mod that makes all the invisible walls visible. No more unexpected behavior. If i jump through the invisible wall I'm willingly taking the risk
I feel like checking for ceiling/oob on at least one adjacent unit and another unit adjacent to Mario's to the side relative the first one (so, search for an 'L' formation) and using a collision in an adjacent unit if not meeting the condition would pretty much solve this at a negligible cost (idk how much frametime this would cost when used but since you are really only meant to collide this way whit these on the level boundaries it's probably wouldn't matter much against the benefit that it would create.)
A video from you today is a birth day present to me❤ Your channel started my love for math and deepened my interest in programming! Serious, you make good stuff in a gamedev and technical way. N.t.: Sorry for the bad english btw
Since people keep suggesting to just put a death barrier under levels, here are 4 reasons why that's a bad idea:
1) You can now fall through the level into the death barrier when there would be holes.
2) Those holes are harder to detect and will be less likely to be caught before release.
3) Slanted walls/floors with vanilla physics can be clipped through pretty easily - the death barrier under the level would make this a lot easier and players would end up clipping into the level all the time.
4) It's more triangles = more RAM = less vroom vroom
death barriers are usually one big square, i.e. two triangles. does that really have much of an impact on performance?
@@dazcarrr its 1 extra nodes per cell and 1 extra iteration per cell. probably like 4us of data throughput more in an average frame and 32kb of extra data used
How does adding a death plane make clipping easier? Is it because there's no longer OoB walls holding you back after you've worked your way through a slope?
Btw I think 3 is the only real concern here, 1 and 2 can both be solved by fixing geometry before applying the death barrier (or the simple fact that most seams are hard to fall into unintentionally), and the death plane is 2 more triangles at most which with modern hardware is a laughable amount of process power lost and certainly more than handlable for an N64. Preventing all invisible walls in 5 minutes at the slight cost of speed and with some seams remaining is more than reasonable as a tradeoff versus spending hours of your life debugging and fixing geometry.
@@Edamori sure but why take a patchwork fix when you can apply a very real fix like i describe in the video.
If you've ever played sm64 x banjo tooie (the one made in 2015ish?) and beat glitter gultch mine you'll see why a patchwork fix is not good enough unfortunately
Now we just need Tom Scott to make a video on Britain's oldest invisible wall and my invisible wall hunger will be complete
an in depth analysis of the history of mimes is in order
"You cannot see it. It's not on any map. You wouldn't even know.. it's.. there" *slow pan over to nothing*
RIP Tom Scott’s posting regiment
@@charlesnathansmithanother perfect Tom Scott parody promt
He'd need an invisible train to yell over in the background.
I was thinking of exactly this after the Pannen video. Then again, I've seen Simpleflips die to nothing enough times to know that invisible walls at the very least exist in some older ROMhacks.
yeah if anything they are more common in romhacks - because romhacks typically have more complex geometry and don't align all their stuff to world axis.
@@KazeN64I subscribed to your RUclips channel
@@KazeN64maybe you can try to rewrite mario 64’s collision type detection next
Shoutouts to Simpleflips
@@KazeN64You've already basically completely rewritten the game from scratch, so maybe you could rewrite the collision detection system?
Yeah, making an invisible wall free version of Mario 64 would be great, but y'know what would be better? Chaos Mario 64: Bonk Edition where practically every vertex in the game is misaligned just enough to make small 1-unit wide invisible walls EVERYWHERE.
That would be a monumental task though.
Maybe an easy way to do that would be to automatically adjust the x,y,z coordinate of each vertex ± 5 units or something crazy small
@@cadelisowe4887 ±1 unit would be more then enough to cause this chaos. Also adding random ceilings everywhere on the floor.
just make the collision check return that theres a ceiling 1% of the time :3c
@@RipleySawzen That sounds so evil, I love it
It could be an effect of Mario 64 Chaos Edition to randomly set Mario to the hard bonking animation state. No need to change any collision :)
It would be even funnier, since then he could randomly bonk on nothing while standing completely still, or completely ruin a jump by bonking midair. For bonus points, if Mario was on the ground as the effect triggered, set his Y speed to be positive so he gets some airtime from the earth-bonk.
according to sm64 logic, the leaning tower of Pisa might be home to the largest and most famous invisible wall, as the wall that leans in doesn't stop the out of bounds hitbox from leaking through
(spelling error, logic error check in progress)
No, it leans far enough for the wall to actually be a ceiling. However, there are tons of little details that would let ceilings leak through even if it wasn't leaning
@@maxtes252 ah then we must see if the other side is floor and if it is subjected to floor overshadowing
pannen showed the to scale leaning a wall can have before becoming a floor and it’s pretty fuckin slight so as much as I’d LOVE to see someone bonk above the leaning tower I think that one’s safe..
but are its vertices aligned?
@@redtaileddolphin1875 just remembered that, gotta reword that
considering it's circular/tube like shape, the walls would probably be on 2 of the sides, not the exposed lean-in side of the wall. unless the scale of wall and floor angles were increased for that wall to qualify as a wall surface
This is false. According to this logic, invisible walls wouldn't be produced in real life, because you can't have missing geometry in real life. Any ceiling necessarily also has a floor on the other side
"I'm sure people would love a patch that does nothing but remove this problem. Someone, get on that." 🗿
This would be easier to make if Kaze released his source code so people could copy from it.
@angeldude101 Yeah I always got the vibe that he just doesn't want anyone doing better than him
@@BigBinky3000 or just "it'll be released after I'm done with the hack"
Coming from Kaze, it sounds like code for "Yeah, I might take a crack at it when I have more time"
@@BigBinky3000yeah I wonder why he doesn’t release it. Maybe he just wants to get paid for all of his work doing that, not just give it away for free online.
As a hack creator, this is way more annoying for the creator to have invisivle wall in his level than for people who play it, the slopes invisible wall is the worst one definitly
Hey, don't be so hard on yourself, I mean I haven't seen your stuff, but I'm sure you're not a hack
@@DouglasZwick When he said he's a hack creator, he means "I create hacks for Mario 64" (e.g. custom maps/ROMs).
Edit: Typo
@@Tony_Goat I was joking, but I appreciate your comment!
@@Tony_Goat It was so, painfully obvious that it was a joke. Please update your sarcasm detector's drivers
@@mochafennec It really wasn't. You wouldn't believe the amount of people who would actually read "hack creator" like that.
First a pannen video on this now a kaze video on it, sm64 community eating good rn
Feeding families
Dang how did you know I just had whataburger
I know I'm a huge nerd for pointing this out but the vertices aren't rounded, they're truncated. Rounding would set the value to the nearest whole number, but instead they convert it to an integer by just discarding everything after the decimal point. This means the vertice would always be set to the next-lowest coordinate value; for instance, 12.9 and 12.1 would both be converted to 12.
Rounded down
@@MateusSFigueiredo Negative numbers round up when truncated. Rounding towards 0.
@@TheRedSmarty oh nice, thanks
Semantics, though. You have a narrow conception of the word "rounding", but a broader conception could include truncation as a type of rounding. Go to the Wikipedia article "Rounding" and then scroll down to the section "Rounding to integer". They literally have a table at the bottom of the section showing many different ways you can round to an integer (including toward 0).
It’s amazing the programmers decided it would be better to work around these bugs rather than fix them. Especially the floor overshadowing; imagine how many times the level designers had to reorder vertices to prevent the same bug over and over without ever realizing their job could be so much easier!
Sometimes gonna finish 🏁
Just goes to show how much of a threat the PS1 was back in the day 😂
The final boss is a convex corner between two walls in a wallkick section
i think frame's rounded walls patch fixed that!
@@KazeN64 i have to disagree, rounded corners hold you back on crossovers, all while not giving you any feedback cue for what is happening, making them worse than vanilla imo
ah, i thought we were worried about invis walls only there. yeah i imagine getting rounded on those corners is not a great experience in kaizo hacks like that
Isn't that already fixed by removing quarter steps? Or to stay more vanilla, just don't allow the wall reference to be deleted in a quarterstep?
@@galoomba5559 That works for glitchy bonks, but there can also be other stuff like indefinitely getting pushed to stay in the corner, and if the floor extends further out than the wall you end up with a deathpixel or at least an edge that will give you a false sense of security for crossovers
It would be cool to have a mod that helps modders see hitboxes like in pannens video, so you could see them leak out
That's what I was thinking the surprise would be at the end of Pannen's video.
It wouldn't be possible for a mod, because you'd need to raycast on every unit of the map to discover where they are, which is far beyond the N64's capabilities. Perhaps with an emulation tool, which is how I assume Pannen did it, though who knows if it even runs in real time.
@@23Scadu I'm pretty sure Pannen used the sm64pc port source to make the visualization tool
A blender addon would be the best IMO (if its even possible)
I just remembered, that there is a tool called STROOP that Pannenkoek and many other members worked on to show almost any information about sm64. I think it can show them, and it might be what is used in the video as well. Not sure about real-time though, haven't looked too much into STROOP.
I wonder if at some point in development they planned Doom-like no-slopes geometry, because none of the errors would crop up with only perfect vertical walls.
I subscribed to your RUclips channel
The edge vertex issues would still exist for stairs and the like.
and by the time they'd abandoned that idea, the code was already written. granted, it'd have to have been pretty early in development, perhaps at the very beginning, since even the earliest beta levels discovered have slopes. but who knows?
@@videopsybeam7220 could also be they just wrote the majority of the code for a very alpha "here's a floor and some boxes" test environment... then never updated it.
Mario 64 was a mess of a development. Parallel teams contradicting each other, rushed dev, cut content at the last moment, an incomplete hardware design, a new method of game design that the team was unaware of how to implement, and Miyamoto in his most tyrannical. The game's code is a mess, a big giant mess held together by code duct tape and luck
seeing the awkward earliest solutions to problems that nobody really had much experience dealing with yet back then is always really interesting
I love how this game is actually a broken mess behind the scenes and still manages to feels almost bug free for the casual players.
N64 games, man
yeah because normal people are trying to play the game as intended and not in some broken way that youre not supposed to be in ...
Error: You killed Mario
2:56
Glad finally to get an explanation of this at the source code level. Just another one to file under S for "somebody please get me some of whatever those developers were on."
EDIT: It later became apparent to me that the goal here might have been to stop Mario clipping inside of entities, ("objects" with "dynamic surfaces," in the game's parlance) like boxes or thwomps, and certain kinds of geometry from below, so it looks like we can refile this under F for "friends don't let friends perform_air_quarter_step."
this is EXACTLY the followup we needed after the inviswall video put the fear of an unjust god in our hearts
To make an invisible wall visualiser like pannen, just rasterize the level top down, at slightly more than the integer precision of vertex, then for each polygon keep track of facing in the rasterize pixel, track the depth span of each wall line at each top down pixel, then draw the vertical span in a regular rendering, to visualize them.
you will have to do this at various heights as some invisible walls are not infinitely tall (and this only finds issues in level geometry, not those caused by objects, unless you want to make a raster view for every possible configuration of objects and heights)
@@MagicGonads you just rasterize top down back to front, and put a per pixel list of state with depth value, then for each list, you remove data that cancel itself...
@@MagicGonadsseeing as an object collision only exists when you are close enough, and almost always will be triggered by the objects own ceiling you can just cast rays from the objects ceiling straight up that stop when they hit a floor triangle.
This is something I never considered until that video last week. Imagine how many romhacks inadvertently add invisible walls without realizing it. The whole invisible wall thing has shifted my view of the game and has made me somewhat paranoid. They can be practically anywhere.
At least we know where all of them are for vanilla SM64 now
for all I know I could wake up with an invisible wall right above my face
there are misaligned edge vertices under your skin!!! careful not to bonk on them.
Romhacks tend to have lots of invisible walls for the same reasons as vanilla, yeah
Will you ever make a "deluxe" version of SM64 where you implement all the quality of life improvements that is known to you?
Can't wait for the release of your game!
That would be pretty awesome
already confirmed, though after release of the main mod
check out HackerSM64 its has a bunch of fixes and optimizations for SM64
I'd really love that but for Mario 64 Star Road.
8:13 6 months of freedom from bonking invisible walls! Congratulations on kicking that habit!
Would ALWAYS having a death barrier beneath the level (Even if you can't fall in it) fix ALL Out of Bounds invisible walls?
sure but then you can fall into it. check out glitter gulch mine in the mario 64 x banjo tooie hack... it tried exactly that
The same vertex misalignment can also cause floor gaps that Mario can get through, making that death barrier reachable.
It does sound like a massive improvement to have 1 unit holes in the ground instead of 1 unit columns of inviswall, especially because it seems like a lot of those holes would be in an unreachable spot right next to a wall.
What I was thinking is instead just have a floor a jump height below the level so if you fall into it you can just jump back up.
@@LocalAitchwell I feel like players accidentally clipping out of bounds by landing or walking in the wrong spot is less bad than having their entire gameplay experience interrupted by an infinitely tall invisible wall thats seemingly there for no reason, so it would still be an improvement
I just realized I’ve been misreading this channel name as “Kaze Emulator” for years
I hope one day we can get a fixed ROM to play this game in its final form.
Super Mario 64 DS has entered the chat
No way a kaze upload immediately after a pannen one
This is the perfect sequel video to Pannen's video.
To manually fix 'holes' in levels with the death barrier, you could remove the death barrier and now check for OOB invisible walls, then put the death barrier back. You still can't find ordinary holes (that just go down to a lower floor that isn't the death barrier), but at least you won't fall out of the level.
It's a good thing this is being more talked about since it means the more it'll potentially be streamlined for developing and playing.
Interesting, I never knew this was such a big and weird issue!
0:28 the one time invisible walls were helpful
I love how at least once every video they say something along the lines of "So this single change I made makes the game work properly and its performance is better".
You could make a drinking game out of it
LMAO i wanna make sure people don't comment something like "okay but now its more performative so that's probably why this bug existed" - because i've gotten so many comments like that about simple changes before.
Please don’t ever stop schooling us about Mario 64. This game holds such a huge space in my heart. Love learning new things from someone that has dedicated so much of their time to it.
Are invisible walls still a thing in that SM64 PC port that came out a few years back?
yes
It is a straight port, so everything including bugs and flaws has carried over.
@@AlexanTheMan It's not. Developers actually took the time to patch bugs and improve quality of life. It's weird no one has patched the invisible walls yet.
@@Accrovideogames That highly depends on what kind of build you got, I'm pretty sure the first one was just put out there with little to no maintenance only to be quickly struck down by Nintendo.
@@bywonline Why not both? Compatibility options could turn bug fixes on and off.
1:03 lmfao this caught me completely off guard.
We need all the modding bros to collaborate on a perfect version of SM64.
Where all it does is fix all of the code and gets the game running locked 60 on actual hardware.
It would be epic.
That Pannenkoek video was so well put together, I can’t wait to see Kaze’s explanation
I was waiting for this video. I hope that one day either you or someone else compiles all your optimizations, while also correcting any floor gaps, to make a bug fixed version complete for Mario 64.
It's planned, but after the main mod releases
The port of all of the improvement-changes to the base game will be legendary, when it happens. Until then, Kaze will continue making the romhack the changes were made for absolutely cracked. It absolutely approaches the territory where one could be fooled for it being an early GC game.
I was hoping you would respond to Pannenkoek's documentary. I knew you already knew about the problem, its causes, and had clever solutions for them in your mods. Thank you for your hard work!
I'm surprised to hear that there isn't a standardized tool for the modding community to use of a visual debugger like in the pannenkoek video that makes it super obvious where the invisible walls are. Does that exist already? Is something like that feasible?
The vertices aren't rounded, they're *truncated*
figuring out where each music comes from was also fun alongside enjoying the video
I love how Mario 64 is the most involuntarily open source program ever made.
Mario 64 code is becoming more reliable than the Apollo 11 code.
I'm honestly surprised that the mod Pannen used to visualize invisible walls isn't publicly available. I wonder why
Seeing videos like this gets me hyped to play your completed optimized original SM64 I can't wait for the release!
Lore of How Modders fight Mario 64's Biggest Problem momentum 100
Finally. Solid evidence that Kaze has seen pannenkoek's "Invisible Walls" video. I can rest easy now.
Based avatar
I never thought that I’d watch so much invisible walls in a week. Nice work btw !
You're one of my favourite invisible wall youtubers, awesome video kaze
I don't understand how this is a problem specific to Mario 64 that we still haven't solved perfectly? I mean how do other games deal with floor gaps?
Actually calculate the coordinates and integer values. N64 is pretty weak nowadays so they had to round the values to save processing power and RAM. You don't want everything to be calculated and lag, so they rounded or 'Truncated' the values, taking the numbers after the decimals (1.1, 1.9) leaving the whole number (1, 1) and apply the collision there.
This leaves gaps if things are at an angle and not whole, like 9.2, or 8.4, as collision is only on the 9 or 8, leaving gaps for out of bounds to leak through or ceiling to leak through. Good optimization, but requires some fixing to make things work properly, as Kaze showed us (Moving the floor under the objects, and cutting the ceiling early.)
I didn't realize it was a nearly 4 hour video until about 30 minutes in. I got scared and ran away.
2:03 I do wonder, would making the collision verticies round up fix any of the issues? Or would it introduce more issues?
Even if the vertex itself is rounded, it won't fix the problem because diagonal edges exist, and diagonal edges don't always line up with the rounded positions.
If you wanted to be mathematically consistent, you should either round to nearest (ties to even), or always round down. Rounding to 0 is almost completely useless, which is why it's the default in C resulting in Mario 64 using it.
Thank you for not posting a 3 hour long video about this
A hidden gift from this video is helping people empathize with how easy it is to miss these things. It's kind of hard to watch Pancake's video and not think the devs were just a little too careless / sloppy. Watching 8:01 is like "ok, yeah, that looks like it sucks."
“Mario 64 is a perfectly made game” average gammer shill
“Ok onto terrible design decisions number 1702” Kaze
Lol true
Don't mind me, I'm just reading the code comments at 3:44.
2:15 that sounds really close to the "slime trail" phenomena in Doom. Luckily those are only visual bugs.
A guy named *Marc ten Bosch* wrote an article about removing quaternions from 3D engines, by reimaging all rotations as happing in a plane rather than around an axis. It's worth a read, check it out when you have the chance!
He also wrote a 4D physics engine (as in four spatial dimensions, not 3D plus time), if you're curious.
I think another way to solve the issue would be to apply wall logics as a result of the 1/4 steps function only when 2 consecutive such test give the same output. Since most invisible wall are thin, they should only detect a collision on 1 while actual wall are thick would still be detected accurately the vast majority of the time.
Also since this logic will always be loaded and CPU is not the bottleneck, maybe it would even be possible to double the test to 1/8 steps so that effect can still apply at the same 1/4 steps despite the fact wall logic would be waiting for 2 positive collision detection.
Of course I think your solutions is better, I'm just thinking of a solution that would result in a minimalistic change vs the original source.
I finally finished watching the invisible wall video and then kaze uploads the sequel, nice
i watched the entire pannen video when it was premiering, this video is a good sequel to it!
If somebody were to mod those visualized invisible walls into base SM64, I wonder if it would be useful for speedrunners to practice with.
The reason they did it this way is, simply, it was the first 3D platforming engine they made, one of the first made anywhere. Roughly contemporaneous with the original Tomb Raider, which has much simpler geometry. It's kind of crazy that Mario 64's areas are so complex, it looks like they took an "art first" approach, where Mario should just be able to navigate arbitrary terrains. The result was a bit janky, but ultimately successful, I think history has vindicated their approach, it formed the foundation of an engine that would be used over and over through the N64 era, and they got much better at doing 3D platforming engines in later iterations.
If you can just get a script that checks the map for small invisible walls and tells you where they are you can move the vertexes a unit or two until the wall goes away then the problem is solved.
Kaze I think it‘s time for a new version of Mario Chaos
I can't believe we have follow-ups for near 4 hour videos regarding invisible walls!
I remember the old days (around 2010) when we didn't even know why it happened, it all seemed random. Making invisible wall-free maps in sketchup was a nightmare
I was hoping to get your opinion after watching that nearly 4 hour long documentary! I think it would be cool if you made a Mario 64: Kaze edition that fixes everything in the way you do it while adding all of your optimizations and optional enhancements like the added lighting effects and extra move set. That would be amazing!
4:37
Mario sunshine has this same collision issue. We noticed nintendo put a really big polygon under the map to solve any potential invisible walls caused by level bounds. why would you generate a lip of geometry inside of the wall or is N64 just that weak that it can't handle large scaled collission triangles 🤔
Every time I watch one of your videos, Kaze, I just want to go model M64 levels or something. You have an inspiring vibe, my man. Thanks for the content, as always.
I mean, out of bounds invis walls are the easiest to deal with, just put a deathfloor in the level (and if you want to emulate the oob level boundaries, just slap big untextured walls on the level). It's a hack, but it works.
Ceilings are harder to deal with due to the inherent problems with the jankass collision system, the best solution is obviously to rewrite it but barring that... follow strict technical guidelines when designing your levels, avoiding split edges wherever possible (even at the cost of making a mesh more dense) and when not possible you have to take care to intentionally cause overhangs rather than underhangs.
It's... workable, it's still better to fix the underlying problem though by either changing how collision works as such:
1) patch OOB blocking and killing mario, encase levels in invisible walls and put a deathfloor at the bottom [even when not normally reachable]
2) make ceiling hitboxes not be infinitely tall (ideally change collision to work like it does in the majority of games actually)
and/or
change to at least fixed point precision coordinates instead of integer coordinates, though the N64 actually has hardware support for fast floating point operations so there's not that much reason to not just go for it. It's a bit slower but such is life. Anyway, fixed point precision maths combined with the technical modeling restrictions mentioned can ensure that there is no 'leaking'. This is a pain in the arse, just fix it properly instead.
For a specific map this could be solved like an integrational tests do: make raycast from each point of inner volume with collision checks run over the Ray’s hits. With such simple geometry on modern hardware it should be quick enough.
yeah agreed that'd be awesome to have as a tool.
Thank you for condensing this down into ten minutes. I started watching that video without realizing it was FOUR HOURS LONG JESUS CHRIST. Props to that guy for being thorough, but goddamn.
a 'stupid' solution to the oob invis walls would be to add a death plane to every world regardless if you're meant to reach it or not. but that would be treating the symptom and not the cause. someday, I would like to see a fixed and optimized sm64 running on intended hardware.
Kaze made a comment explaining why that's a bad idea
I still wish that the subscribe button from your outro was a series of [!] floor buttons that looked like a single long rectangular button and had the subscribe text on top, and maybe their origin sits below the map, so when Mario runs through them and presses them, it reveals the "subscribed" gray button as a map texture. Finally, the last button gives Mario the star.
In pokemon sun and moon, we have the same inacurate stairs collision physics
the reason they made ceiling hitboxes go up until it hits a floor is so you cant clip inside thwomps as they squish you at high speed. with your patch it will be surprisingly easy to clip through the few in the game with a well-timed jump as the thwomp's ceiling hitbox combined with mario jump will move through mario fast enough to get through it within a frame and then mario has all these weird hitbox interactions within the thwomp like walls and floor on its top that will let mario escape unscathed. Their implementation stops mario from moving into the thwomp if the speed is too high and sticks him in place. they wanted squish mechanics to be "fool proof" its also why they have priority over other hitboxes too.
They are 500 coordinates in size. Their max vel is 75. Marios max vel is about 80. You cant even get 1/3rd through them. And if you could, the bug would be the same with and without the changes
@@KazeN64 is "they" (500 coordinates) your new ceiling hotbox or the thwomps? it sounds like it's the thwomps from your reasoning that the bug would exist in either case but you don't need to go through the entire thwomp if the ceiling doesn't go up until it reaches a floor like your patch.
Even if this did break the Thwomps, one could just tweak them instead. There is no good reason to just make ceilings "infinite until stopped" across the board.
@@lpfan4491 yeah it isn't a good reason but I think it's why it's done like that
Yes it does seem possible that checking from the floor height to the ceiling may have had something to do with preventing Mario from clipping into a box or something similar (not just thwomps) from below, now that I think of it. Remember, though, that Kaze's changes include chucking the whole mad quarter_step scheme and just validating each move all at once by searching for any surface between the old and new positions. If Mario would have passed through the ceiling on the the thwomp's underside, he won't clip inside under this system, no matter _how_ fast he or the thwomp is moving.
A level deliberatly themed around invisibke walls has potential.
I always love all of your videos, even cooler to see your video after Pannenkoek's one! I have one question: I'm pretty ignorant, so I'm probably missing something, but doesn't removing quarter steps make you also need 1/4 of the speed to clip through walls? Like, the sliding speed you get on slides of 100 should be enough to clip through a wall, considering you normally need less than 400 speed to do so. Maybe I'm missing something though
usually yes - but i use the move validation to raycast from mario's old position to his new one to check if it passed through any geometry. that way i can just snap mario back and check if a move there is valid. that prevents all movement through walls.
@@KazeN64 oh, I understand, that's great! Thx for the explanation!
You don't need to check 4 discrete positions for wall collisions when you can just do what most games do and check the entire continuous path instead. This is what ray-casting is for.
If we ever get to see time machines in our lifetime, I see you going back to 1995/1996 and work with Nintendo to release a polished version of Super Mario 64.
surely a good way to circumvent the out of bounds invisible walls would be to just add a death barrier even when one is not needed.
And if you use out of bounds as the border of your level, just have the out of bounds floor be a silhouette of the stage. Sure extra polygons aren't great, but i feel it wouldn't impact performance much
His mod has been in development longer than super mario 64 itself.
Thank you for the trunkated version Pannen's video. I'm about 3 hours into rhe video and still have an hour to go. I will still watch it to its end. Just I think it's good to have a shorter version out there for people who just want to gwt the gist of it.
If vertex placement and alignment are important, avoid Merge By Distance because it averages the vertex positions. Instead use Merge At Last with the last vertex selected being the one at a correct position.
1:59 So what would happen if the collision vertices were not rounded/truncated? Would this completely eliminate the misaligned edges? Could this be a practical solution?
collision would be a lot more expensive so that's not something we should want
yipeeee new kaze emanuar upload
The problem with removing all invisible walls is that some speedrunning tricks rely on certain ones.
The fusion of Pannen and Kaze would rewrite the entire code of mario 64 from scratch and have it run at 4k 120fps on original hardware.
yknow, i wonder how much would be fixed by just, like, making ceilings not go on forever, and by making Out of Bounds some kind of specifically-set thing or whatever
I'd love a mod that makes all the invisible walls visible. No more unexpected behavior. If i jump through the invisible wall I'm willingly taking the risk
Didn't pannen use that for his video? Because no way he animated all that, that would be crazy
I feel like checking for ceiling/oob on at least one adjacent unit and another unit adjacent to Mario's to the side relative the first one (so, search for an 'L' formation) and using a collision in an adjacent unit if not meeting the condition would pretty much solve this at a negligible cost (idk how much frametime this would cost when used but since you are really only meant to collide this way whit these on the level boundaries it's probably wouldn't matter much against the benefit that it would create.)
the title of this video is a question i had in my mind ever since i watched the Pannen's video
I played SM64 for a few months already, and yet I haven’t experienced even one invisible wall.
Mario 64 was programmed on sticks, glue, duct tape and dreams. It is a wonder Nintendo got it to work at all!
A video from you today is a birth day present to me❤
Your channel started my love for math and deepened my interest in programming!
Serious, you make good stuff in a gamedev and technical way.
N.t.: Sorry for the bad english btw
All those aligning and merging fixes for vertices are why you should use blender and not sketchup! I learned this the hard way.
Wouldn't the easiest solution to the floor gaps be "just add a death floor to every level whether or not it should be accessible"?
I knew you'd make a video after that absolute masterpiece by pannenkoek!
7:38 hold on is that Dorrie? omg