As a change of pace from glitch explication, I want to dissect something that is not a glitch, but it's something everyone immediately labels as one. But it's not a glitch, nor is it necessarily the result of one. There are ways to use glitches to trigger the Houlihan warp, but that just means the code is doing its job. Instead, the Houlihan is an easter egg that's been built in as a failsafe, and it's one of the few general failsafes to exist.
To start, I'd like to clear up the second biggest misconception, which is that triggering Houlihan is the result of a messed up camera. That's not exactly really true. The camera matters, but only indirectly. What really matters is your X-coordinate, Y-coordinate, and screen ID.
This is the easiest to explain. It's your screen's… ID… Basically "which screen are you on?" Except instead of saying "Oh, I'm in Kakariko.", it's the CPU reading address $8A and saying "Oh, you're on screen $0018."
Your coordinates together are used to calculate a location in Map16 (which, to keep it brief, is how overworld tiles are stored to keep them, their graphics, and their behaviors "easy" to control). This location is then used in part of the search for where the hole goes.
This may sound silly, but your X-coordinate is easier to explain than your Y-coordinate. Why? Well, it's taken as what it is when you fall into the hole.
Your Y-coordinate is a little trickier. When you fall into a hole, your Y-coordinate is modified to be placed above the screen. Here's exactly how the routine goes, starting from when we're finally ready to warp:
Hey! We're outdoors! Let's follow that branch!
16 to it, then put that new value in scratch space.Overworld_Hole.So ya, the routine tries to put Link at the top of the screen for later stuff. Some of you may be screaming, "SO THEN IT'S THE CAMERA!", but it's not that direct. The vertical scroll of the camera matters only because it determines your Y-coordinate. The horizontal scroll of the camera is completely irrelevant.
Another subtlety that should be pointed out is that you may sometimes notice the camera jerk upwards after you've fallen into a hole. This happens after the Y-coordinate recalculation, so that's irrelevant as well.
Now that we know the variables used and how they're determined, let's take a look at the actual routine that finds our destination, Overworld_Hole:
If the loop reaches -1, set the pit index to 19 (remember: 0-index), and put Link in the Light World.
So what exactly makes this not a glitch? A glitch is something that is not intended by the developers. But if you look at this code, it's pretty clearly intended. After all, they promised a Mr. Chris Houlihan his name would appear in the game. What better way to technically fulfill that promise than an obscure fail-safe room?
No seriously, this code is sloppy. Here's the vanilla code:
Seriously? Who knew 14 bytes could be so lame? Here's my better code, which uses space and time more efficiently:
Ya, that's it. 6 bytes. The branch in my code would be 6 bytes further (accounting for the stuff I removed), hitting the instruction REP #$20. X should be 16-bit though, so we need to change that to REP #$30. Same number of bytes though.
PEI is an underused and underrated instruction that pushes the 16-bit value in the address it holds to stack, regardless of the accumulator's or index register's current bit mode. In this case, it also makes way more sense than swapping bitmodes just to push to the stack, which also required a mask o—… Wait a second. No it didn't. Even if you wanted to do it this inefficient way, why would you set the accumulator to 16-bit and immediately load what's intended to be an 8-bit value? REP #$30 should have come after the LDA $1B. It wouldn't affect the Z flag, and it would have removed the need to mask the accumulator before the branch check.
When Link falls into a hole on the overworld, the destination is determined by both the current screen ID and his X- and Y-coordinates. As a small catch, before this even happens, Link's Y-coordinate is determined by the top of the camera. Although the camera can move after the Y-coordinate is recalculated, but before the destination is. So calling it camera-based is only about one-quarter correct.
Destinations are in a list, which is looked through for a match from the input parameters. If every item is looked at without finding a match, then the Houlihan Room is used as the target destination.
This is one of the few failsafes added to the game. No matter how you slice it, the game is doing exactly what the developers wanted it to do. And because it is possible to trigger the failsafe without doing any actual glitches, calling Houlihan a glitch is patently wrong.