Posts and replies

For reference, here's my writeup on the previous route on Wii: https://nitter.poast.org/MrCheeze_/status/1418307382728437762

But I'll also explain how the new one works, in a way that shouldn't depend on reading that.

The key tool used in both the previous Wii route and the new Wii U one is called "Lightnode SRM".

The effect of this SRM is that it takes the eight bytes of your filename - let's call them AAAAAAAABBBBBBBB - and does two different controllable ram modifications based on it.

Specifically, it writes the value BBBBBBBB to address (AAAAAAAA+8), and the value AAAAAAAA to address (BBBBBBBB+4).

If you think about this for a sec, you'll see that this means we can either modify _one_ important address to have a fully-arbitrary value... or we can modify _two_ important addresses, but without very much control over the written value.

In order to trigger the credits in Ocarina of Time, two different effects BOTH need to be triggered at once:
1) You need to load a new scene (map), and
2) You need to set the game's "current cutscene" variable to a certain value.

Only certain specific combinations scene and cutscene will play the credits. Achieving this using the effect of lightnode SRM is quite difficult.

So difficult, in fact, that the only way that we knew how to do it for the past three years involved exploiting a hardware bug (!) exclusive to the Wii.

I go into this in more detail in the thread I linked above, but a very-brief summary is that on Wii, if you write to a memory address that is "misaligned" (not a multiple of four), and "uncached" (the high byte of the address is C0 instead of the usual 80) - then the console won't just write to the address you specified, it will also write to some of the surrounding memory.
(A fun fact is that this hardware bug was used in old versions of the Homebrew Channel to detect whether it was running in Dolphin Emulator or a real Wii.)

Anyway, that hardware bug was just useful enough that it allowed us to set both the current cutscene AND trigger a fake loading zone on Wii, which was enough to credits warp.

Now, the _theoretical_ fastest version of Ocarina of Time is the Switch version, the second-fastest version is the Wii U version, and the third-fastest is the Wii version. The sole reason for this is lag: each rerelease of the game on a newer, more powerful console, has less lag than the previous. It's enough difference that you actually save whole seconds by upgrading to a newer console.

That said... the Switch version is never going to be the fastest version for any% speedruns. The reason for THAT is a little off-topic, but it's kind of interesting so I'll explain it anyway:

In order to set up Lightnode SRM (or any other SRM effect), we need to arrange things in specific spots on the in-game heap. Normally, OoT's heap contains both code and instance variables for all the actors (objects) that are currently loaded.

On the Switch version specifically, however, actor code ("overlays") are NOT stored on the heap. They actually made the emulator specifically inject some game-specific hacks to prevent them from being stored there! ( https://pastebin.com/Baj7STxd )

Why did they do this? Because in order for the Switch to execute N64 code, it has to uses a JIT to dynamically recompile it into Switch native code. For some reason, the Switch N64 emu has a slow recompiler that causes noticeable lag and audio glitches when doing this. And when actor code is stored on the heap, that means that this lag happens whenever actors are loaded.
That's why they injected a game-specific hack that makes it so that actor code loads at a specific, fixed address instead of loading and unloading in the heap. It uses more memory, but it saves having to recompile the code over and over.

Because of this change, the heap has different contents, and the manipulation we do to achieve Lightnode SRM just happens to be much slower than the manipulation used to achieve the same effect on N64/Wii/Wii U. So, the Switch is not the fastest console for speedruns.

The idea that I had was to corrupt the *game code itself* that is used to detect whether Link is standing in a loading zone or not. (This is possible because the N64 loads all code to ram before executing it, it doesn't execute from ROM.)

If you remember my explanation earlier about what Lightnode SRM lets us do - we can write to two different precisely chosen memory addresses, as long as we're not choosy about what VALUE we're writing there.

So, the hope is that by writing any random junk value into the "detect if standing in a loading zone" function, that will effectively NOP out one of its instructions and cause it to detect a useful loading zone.

That would be one of the addresses we write to. The other address would simply be the "current cutscene number" variable.

With a fair bit of trial and error (and some emulator automation), I was able to find a filename that both 1) corrupted the function in a way that triggers a useful loading zone, and 2) corrupted the current cutscene number into a value that, when combined with the loaded entrance, triggers the credits!

Which sounds like a strangely lucky coincidence, when you remember that we can't really control what value is written to the two addresses. (again, the value written to address A is a pointer to address B, and vice versa).

And in one sense, yes, it's a lucky coincidence - but not really, because this is one of a dozen similar ideas like this that I've had to try. Sooner or later one of them had to pan out and write useful values, so that's the one that gets a writeup :D

Anyway, as soon as I came up with that idea, I sent it to bradyONE - the creator of the video at the top of this thread - for testing on a real Wii U. He's been a huge help for the last few days, not only for testing this idea but others that ended up not working out. And he found that it works perfectly!

The moment he confirmed that, we knew that OoT any% had a new route and was switching from Wii to Wii U. But there's a few more points of interest to talk about.

First, something funny: I mentioned that we corrupt the function that detects if Link is standing on a loading zone. The corruption actually has other effects too - it seems to change the lighting properties of all floor polygons, in a way that turns Zelda and Link purple in the ending - or as I've taken to calling them now, Hilda and Ravio.

Secondly, the speedrun being on Wii U means that we have some interesting new options for a certain other part of the speedrun. I haven't mentioned that part yet, although it's actually what brady's video above focuses on.

For both the Wii route and the Wii U route, at the very end of the run, you need to drop Link's hands while facing a certain EXACT angle. Because the speedrun is so short and optimized, we want to be able to turn Link to that exact angle as quick as we possibly can.

As it turns out, there's a very fast way to do this, thanks to some quirks of how Wii U handles controller input...

There are two facts to know about controllers on Wii U VC. The first is that if you have a Pro Controller/Classic Controller connected to your Wii U, you're able to control the game using that controller AND the gamepad, simultaneously.

By which I mean: if you press a button on either controller, it will be sent to the game. For the control stick, the Pro/Classic controller takes precedence over the Gamepad controller stick.... but the gamepad stick is used if the pro/classic controller stick is in the neutral position.

The second fact is probably the funniest part of the new route: The Wii U gamepad has built-in tv remote, and this functionality is somehow IMPORTANT FOR SPEEDRUNS.

Specifically, there is a "TV" button on the gamepad that opens a tv remote menu. Whenever this menu is open, all buttons and stick inputs from the gamepad are suppressed - you can press buttons and move the stick, but they won't actually get sent to the game.

In addition to those two facts about Wii U controllers, let me say one general fact about the game. There is one specific joystick position that will turn Link towards the exact angle needed, if you have the stick in that position for 1-3 frames.

These three facts give us a method that is both fast AND consistent to achieve the Link angle!

First, before the speedrun even begins, you take the gamepad joystick, and carefully move it to an exact, measured position. (There is certain practice tools that can be used to confirm the joystick position is correct).

Then, use rubber bands (!!) or something else to permanently fasten the gamepad joystick in that position.

Then, press the TV REMOTE BUTTON (!!!) to suppress the gamepad input - the gamepad stick input will be ignored until we close it.

Then, put down the gamepad, pick up a pro controller/classic controller, and do the first 95% of the speedrun using it.

At the very end, when you need to do the angle setup, here's what you do:

First, close the tv remote menu (by pressing the tv button again, or using the touch screen). This will cause the precisely measured stick position to be used.

Then, 1-3 frames later, press the R button to, and Link will drop his hands at exactly the correct angle.

Then, all you have to do is hold up on the pro controller joystick, and it will take precedence over the gamepad input. Just walk over the loading plane in the hallway to the Deku Tree, and the lightnode SRM we've been setting up will trigger, instantly warping you to credits!

I think that's all I have to say about the new route. Since we've known for years that Wii U SHOULD be faster, but had been unable to find any setup that would work for it, I find it extremely satisfying to have finally done so.

What I didn't anticipate, though, was that the new route (or rather, the new console) would have an advantage besides saving time. The fast+easy angle setup described above is totally new - on Wii, runners just flick their stick towards the precise position, and hope they happened to get it right. A lot of runs fail due to getting the flick wrong, so eliminating that problem is a very nice bonus.

Also, there's one obvious question to ask: is this the final route for Ocarina of Time any%? My semi-educated guess is "yes, at least for the currently released". My reasoning:

- If you consider only N64/Gamecube/Wii/Wii U, this is the fastest that the run could possibly be. It uses the least laggy of the four consoles, the heap manip is *extremely* fast, and it credits warps the very instant that you achieve your SRM effect.

- Switch would theoretically be faster (due to less lag) if it had an equally fast heap manip. But in all our searching we never found one, and I personally don't believe it exists.

- Hypothetically, for some future console (let's say the switch 2) they might do yet another release of ocarina of time. If that console's release did NOT have the game-specific hacks that mess up the heap on Switch, then it would be the new optimal console for speedruns! (I do kinda fear that they just keep using the heap hacks from the Switch version forever, though.)

So yeah, I do predict this to be the final route ever. But of course, I've made that prediction many times before, and it's been wrong every time
It's always a great thing to be proven wrong about!

BONUS: here's what the gamepad looks like when using this setup (courtesy of bradyONE):