One of my main OOT and MM hacking projects was trying to port some of the different in-game areas, or "maps", back and forth between the two titles. As you can see in the above video, I had some success in porting maps from MM into OOT, but I never was able to port anything from OOT to MM.

This trick is possible because the MM game engine is simply a modified version of the OOT engine, and the structure of the internal files they use to store the map data is nearly identical between them. Indeed, the MM map format is basically just an extension of the OOT map format.

Relatedly, that's the main reason why I couldn't port anything from OOT to MM. At the time, the MM extensions to the map format were almost completely undocumented, so while OOT just ignored the extra data in the MM map files, I didn't know what to add to the OOT maps to get them to work in MM.

As a part of my effort to figure out how to port OOT maps into MM, I started trying to reverse-engineer the undocumented MM-specific extensions to the map file format. More precisely, I was flipping bits and changing values in the ROM with a hex editor and seeing what had changed in-game as a result.

One of the map format extensions seemed to govern in some way the behavior of the camera; as I was experimenting with it, I accidentally created the exaggerated visual effect in the video above.

Note that I conducted these experiments on the leaked debug build of MM, hence all of the unusual text and other information being printed onto the screen.

Since my OOT-to-MM map porting experiments had hit a dead end, I decided to shift gears and try something different: Extending the data structure in OOT that enumerates all of the various levels, or "scenes", of the game (hereafter called the "scene table").

To do that, however, I had to make a number of modifications to the assembly code for the game, since I needed (among other things) to allocate some space in the game's memory into which to load the files and custom code I'd injected into the ROM.

At the time, the documentation of the game's assembly code was sparse at best, so a considerable amount of trial and error was involved in locating the correct functions to hook and call, and one such error with the memory-allocation function resulted in the contents of the video above.

The little colored icons in the bottom-right corner are from me mashing the A and B buttons to try and load the title graphic. Also, I still have no idea why the Z-targeting sound effect plays part of the way through the cutscene.

After my last project, I had a falling out with the Zelda 64 ROM hacking community, so much so that I was completely soured on ROM hacking for a few years. I never rejoined the community, but after a while I wanted to make more hacks.

By that time, I was feeling much more ambitious: I wanted to try making a brand new OOT map from scratch, using nothing but a hex editor. It was very tedious work, as you might imagine, but I eventually got the level shown in the video above working properly.

The observant viewer will notice that there's no proper floor, ground, or other such terrain to be had; all of the standing room is made from moving and interactive objects instead. As it turns out, defining collision data and textures using a hex editor is torturous, not that that later deterred me....

Despite how my last attempt to make a new OOT level from scratch using only a hex editor left me burnt out from the monumental tedium of it, in an act of sheer masochism I did it again about a year later. This time around, I took a stab at defining proper collision with textures and everything for the terrain.

I'm still happy with how it turned out, but defining the collision and textures for even a single one the platforms shown in the video took literal hours of painstaking copying and correcting, with no real way to debug the result whenever I would place a vertex incorrectly or some such.