SM64 Moat Skip Description

The ability to enter the moat door underwater comes from a glitch that has long been known, but poorly understood. Many players have noticed that by BLJing in certain spots, such as on an elevator, it's possible to get strange behavior to occur. On console, the game typically freezes, but on emulators and even Nintendo Virtual Console, Mario can warp to a weird invisible area. This behavior is often confused with Mario going out of bounds, but that's actually not the case. It turns out that in addition to the collision map present in the level, there are also an infinite number of invisible copies of the collision map spaced out in a 2D grid, extending to infinity. These copies, which we've been calling Parallel Universes (PUs), contain the exact same layout of floor and ceiling collision triangles as in the real map, but most everything else is missing. In addition to being invisible, there are no walls, no water, and most loaded objects are gone as well. Some things are still present however, like paintings in the castle.

 

The missing water is especially significant here, because the water is what prevents Mario from opening the moat door in the first place. Now, it's not enough to simply go to a PU, because even though the moat is empty, the door isn't there either. Instead, the empty moat allows Mario to approach the door in the real map simply by running into it. The problem with doing this in the real map is that the water prevents Mario from getting low enough to do this. There is only 1 frame to open the door underwater before he enters a swimming state, and landing from the air prevents him from opening a door for 3 frames due to dust, so he HAS to run into the door. The empty moat in PU allows us to do just that, but it's not a trivial task.

 

In order to access PUs and control Mario's position within them, it's important that Mario's speed is an integer multiple of 2^18, or 1 QPU (2^18 is equivalent to a point 4 PUs away, so we refer to it as 1 quadruple parallel universe ---> QPU). Unfortunately, this speed can't be quickly obtained in the castle grounds becasue there's no good BLJ spot. There is another trick named hyperspeed walking that we're almost certain works, but it takes far too long to be useful in a speedrun. Instead, we make use of an obscure glitch in the Vanish Cap Under the Moat course. When Mario falls through the death barrier at the bottom of VCUtM, he spawns in water at the base of the waterfall in castle grounds. This is important because it preserves Mario's speed, which can be restored by pressing Z when exiting water (common SM64 TAS trick). Since VCUtM has elevators, we can build the necessary speed there, and use it outside of the castle! Getting a speed that works for both VCUtM and Castle Grounds was very tricky, however I'm not going to go into too much detail about that here.

 

Although going to PU has been known to pretty much always crash on console, we figured out a way to prevent it (Shoutout to Kyman for confirming this on console)! Simply switching R Camera to Fixed Camera Mode and holding R before going to PU is enough to prevent the crash. Because of this (and another glitch that will be revealed soon), we anticipate some significant improvements in multiple categories. Although the only proven way at this time to enter VCUtM with the moat raised is with hyperspeed flying (which requires 10 stars for the wing cap), we're working on a faster 0-star method that will hopefully make this strat viable for an updated 0 stars TAS. Even without this, we expect sub 5 0 star times due to an impending PU improvement in BitFS!

 

Finally, for those who want to know why the PUs exist at all, it comes down to an integer overflow glitch. Even though Mario's position coordinates are floating point decimal numbers, not integers, the game's code typecasts them to signed short (16-bit) integers for the floor and ceiling collision calculations. Short ints have a limited value range: they can be as low as -32768 and no higher than 32767. So if a number goes outside of this range it will "overflow" back to the other end of the range. For example, if Mario's X coordinate was 40000.0, when converted to a short int it would become -25536, as being larger than 32767 causes it to wrap around to the negative side. So for the purposes of the floor and ceiling collision calcs, adding or subtracting an integer multiple of 2^16 to a position coordinate has no effect!