But first, we need to talk about Parallel Universes.

But to answer that, we need to talk about parallel universes, and if you thought my other tangents were complicated, just you wait.
Okay, so Mario's position is a floating point number, but it's converted to a short when the game uses it to detect collision with floor triangles. In other words, Mario's position can basically be any decimal number, but it's converted to an integer between -32768 and +32767 inclusive. So, any fractional portion is truncated, numbers too big or too small are moved into this range using the modulo operator. Graphically, that means that the position used for floor detection is always inside of this box, so if Mario's in that box, then his actual position and the position used for floor detection are the same, albeit maybe off by a single fraction due to the truncation. But if Mario leaves that box, then his actual position and the position used for floor detection will separate, since the position used for floor detection will separate, since the position used for floor detection will just loop back around to remain in the original box.
So now I ask you this: Here's the course, so if Mario is standing way over here where there's no land, but the position used for floor detection is on land, can he stand over here? The answer is "yes." As far as the game sees it, Mario is in fact above land over here, because the game actually checks for land over here. So, for all intents and purposes, there is essentially land over here; a copy of the original map. And this is what we call a parallel universe, or a PU. And this applies to every one of these boxes, so there's actually a grid of nearly infinite PUs.
Here is a to-scale diagram of the PU grid. As you can see, the PUs are actually pretty far apart, but I'll be taking some creative liberties and drawing them closer together for the sake of clear visuals. Now PUs aren't as glamorous as you might think. The graphics are only found on the original map, so the PUs are completely invisible. Furthermore, PUs have no objects, like elevators or item blocks, no enemies, no items, like coins or stars, and not even any walls, so really, it's pretty barren. Furthermore, the N64 console will actually crash if you go to a PU and let the camera follow you, but luckily we can avoid that crash by fixing the camera in place on the original map before leaving it. Though, that does make it even harder to tell what's going on in the PUs.
So, as you just saw, you can travel to a PU if you have enough speed, but it's not as simple as you might think. If you have just enough speed to reach the PU one over, it won't actually work. That's because the game actually checks if he's on land on each quarter step of his movement. That means the simplest PU movement is moving over 4 PUs at once. That way, each quarter step is above land, and therefore valid. For simplicity, we call this quadruple PU distance one QPU.
Now, up until this point, I've been glossing over a very important detail, which I now need to clear up. What if I told you the distance Mario moves isn't necessarily equal to his speed? For example, look how fast Mario moves at 31 speed on this flat slope, and now compare it to how fast he moves on this steeper slope. In both cases, he's moving at the same speed, but clearly he's moving at different rates. That's because the distance Mario moves is only a portion of his actual speed. And this portion depends on the slope of the ground. The steeper the slope, the smaller this portion is. Note that it only depends on the steepness, not whether Mario's facing uphill, downhill, or sideways on the hill. In these visuals, blue will represent Mario's actual speed and green will represent the portion of it that he moves, which we call Mario's de facto speed. So in these 3 pictures, Mario has the same speed, but he has different de facto speeds since he's standing on slopes with different steepnesses. So, if we want to move 1 QPU, it's not sufficient to have QPU speed. We need QPU de facto speed, which often means our actual speed will need to be greater than 1 QPU to compensate.
So to reiterate, we need to increase our speed until our de facto speed syncs up with 1 QPU, and the speed needed to do this is called the syncing speed. So in this diagram, the blue arrow represents the syncing speed. When we have that speed, the quarter steps of the de facto speed sync up with the PUs, and we can move. Now, what I'm showing here is just the lowest, or first, syncing speed, aka the speed needed to move exactly 1 QPU. If we increase our speed, eventually our de facto speed would sync up again when it covers a distance of 2 QPU, and so we'd be able to move at that speed, which is 2 times as fast as before. So, in general, any multiple of the lowest syncing speed is itself a syncing speed, and will cover multiple QPU at once. So remember, every slope has a different set of syncing speeds, and this can make routing tricky.
For example, in the video where I do PU movement to reach the secret aquarium, I had to traverse several different slopes. First, this slope which I used for hyperspeed walking, then this slope at the edge of the water, then the flat ground of the castle foyer, then the castle stairs which is really a steep ramp, and then the flat ground of the upstairs, and note that the stairs that you see there are actual stairs and not a ramp, so they're just flat ground. Here is a graph showing the syncing speeds for each of these slopes, and so these are the speeds I need to have PU movement while standing on each of these slopes. Naturally, the steeper slopes have greater syncing speeds.
Now keep in mind that I can only build up speed while I'm on the hyperspeed walking slope. Once I leave it, I can't generate any more speed. So my speed will only decrease from there. So to successfully perform this PU route, I better have generated enough speed to meet each slope's syncing speed in turn. For example, let's say I build up enough speed to reach the 1st possible syncing speed, and I use that to go to the next slope. Then I could let my speed drop until I reach this slope's syncing speed, go to the next slope, let my speed drop again until I reach THIS slope's syncing speed, go to the next slope, but then I have a bit of a problem. I have less than the required syncing speed and no way to gain any more. So is this route just impossible? Well, no, because these are just these slope's first syncing speeds. But remember, any multiple of these will work at well.
So now, let's factor in each slope's second syncing speed as well. These speeds allow Mario to move 2 QPU at once instead of 1. So now, if instead build up enough speed to reach the second syncing speed of that first slope, then I'll actually have enough speed to meet each syncing speed in turn and complete the route. And if that didn't work, we could consider each slope's 3rd syncing speed and so on until we did get it to work. However, which syncing speed we need to reach initially is kind of a big deal, because reaching that first syncing speed takes about 12 hours, and reaching that 2nd syncing speed takes about 25 hours. So if there's a way to use a lower syncing speed initially, then that's a 12 hour save.
So, how much speed will we need to generate for the "Watch for Rolling Rocks" star? Well, keep in mind that even with access to unlimited horizontal speed, we don't have any improved vertical mobility, so to get to the top of the course, we need to travel up slopes and ride up elevators. So this will be the basic route: start on the hyperspeed walking slope, navigate along the path up from the lake, ride up this elevator, ride up this other elevator, make your way onto the "Amazing Emergency Exit" platform, which is the highest point we can reach, and then launch to the "Watch for Rolling Rocks" platform. By itself, that still won't be enough height. But, the scuttlebug we positioned will provide the extra bounce we need.
So this is the graph of the syncing speed of each slopes. Unfortunately, we run into a bit of an issue with the path up from the lake. That area is actually made up of dozens of floor triangles that each have different slopes. But that didn't stop me! After careful observation and scrutiny, I isolated 6 triangles which I named "T1" through "T6." These triangles have strictly decreasing steepnesses, so we can meet each of their syncing speeds in turn. Additionally, their heights span the entire vertical distance we need to cover to go from bottom to top, without leaving any gaps in between. So, by using the slopes of those 6 triangles, we can complete the blueprint for our route, allowing us to utilize the first syncing speed of the initial slope, so building up speed only takes 12 hours instead of 25.
Now we're almost ready to go back to the video, but there's just some final points I want to make. For example, we don't need to have exactly the syncing speed to traverse PUs. If you have slightly less than the syncing speed, you'll move relatively forwards in the map. If you have slightly more than the syncing speed, you'll move relatively backwards in the map. And the further you deviate from the syncing speed, the greater this relative movement will be. Additionally, if you adjust your angle slightly away from the cardinal directions, you can move relatively sideways, but keep in mind that even the smallest possible angle deviation will be magnified over the QPU distance, and thus Mario will be sent multiple feet to the side.
Now based off what I've told you, you might think you can travel only multiples of 4 PUs at a time, but that's not actually true. For example, if one of your quarter steps is out of bounds or over a ceiling, then that quarter step will be invalid, and since Mario moves up to but not including the first invalid quarter step, he can in fact end up stopping prematurely at one of the quarter steps. Seperately, if you change slopes during a quarter step, your de facto speed will change and you'll alter the distance of the next quarter step, so most likely it will no longer sync up with a PU and you'll end up stopping on the new slope.
Finally, for simplicity, the set of PUs that are multiples of 4 away we call the "QPU grid," and if Mario's on the QPU grid, we say he's "QPU aligned." Remember, moving a multiple of 4 PUs is easy, but moving a different amount requires special conditions like out of bounds or changing slopes. So, if your QPU aligned, it's easy to stay that way, and if you're QPU misaligned, it's easy to stay that way as well. Now, if you become QPU misaligned, you'll need to correct that in order to return to the main map. But, that can be difficult if you're not near out of bounds and your sequence of slope changes is pre-determined. So, managing your QPU alignment is one of the many challenges of planning your PU route.