The Legend Of Zelda: Decompiled

Keeping source code to programs closed is something that is generally frowned upon here for plenty of reasons. Closed source code is less secure and less customizable, but unfortunately we won’t be able to convince everyone of the merits of open source code any time soon. On the other hand, it is possible to decompile some of those programs whose source remains behind locked doors in an attempt to better understand that code, and one of the more impressive examples of that of late is this project which has fully decompiled The Ocarina of Time.

To get started with the code for this project, one simply needs to clone the Git repository and then use a certain set of software tools (depending on the user’s operating system) to compile the ROM from the source code. From there, though, the world is your rupee-filled jar. Like we’ve seen from other decompiled games, any number of enhancements to the original game can be made including increasing the frame rate, improving the graphics, or otherwise adding flourishes that wouldn’t otherwise be there.

The creators of this project do point out that this is still a work-in-progress as only one of the 18 versions have been completed, but the fact that the source code they have been able to decompile builds a fully-working game when recompiled speaks to how far along it’s come. We’ve seen similar processes used for other games before that also help to illustrate how much improvement is possible when re-writing old games from their source code.

Thanks to [Lazarus] for the tip!

13 thoughts on “The Legend Of Zelda: Decompiled

  1. While amazing work on it so far. The headline on the MVG title is just plain wrong. It’s only partially done, and stuff could still break if code is moved around (called “shiftability”)

    Note that there is work done on all zelda games:

    I’ve done some work myself on the LADX (gameboy) one. Which I also wouldn’t call anywhere near “fully decompiled” even if it’s mostly shiftable, I know of a few odds and ends that can still break.

  2. Frowned on? That’s a bit entitled and ungrateful.

    I certainly don’t expect everyone to released the fruits of their labour for free. Those that do, get my respect. And support if I use their stuff.

    1. While that may be true about games and other media that are more akin to works of art than research material, I simply can’t understand it for other kinds of software. When I need something, I code it, then I make available to others to improve; if it exists, I add the functionality I want or fix the issues that annoy me. If that’s outside my knowledge, I send a tip to someone else who can do it. The software “market” wasn’t a thing originally, and it is progressively going back to that. Nowadays people would laugh at you if you said you want to sell your operating system or web browser. Games by nature don’t follow that logic: they are just for entertainment and don’t really compete for niches, so it makes sense that developers can actually “sell” them.

    2. Fruits of their labor? That’s a bit dense and half baked. What are you talking about? It’s 2021, what kind of code could be written that thousands, possibly hundreds of thousands of people, couldn’t possibly write themselves? People that are hacking these things have clearly, already bought their product you dolt.

    3. This is hack a day, the “Open source is the best thing since slice breed.” community, or at least some makes articles in that fashion…

      My own opinion is that open source and closed source software has their own merits, their own pros and cons.

      I personally think a programmer or organization/company is entitled to get some monetary compensation for the work that they have done. As to be able to continue doing more contributions and to uphold/service what they have created so far. Open source projects don’t tend to pay one’s rent after all.

      This however doesn’t mean that all closed source projects are “perfect”, a lot are actually quite abhorrent….
      But likewise, a lot of open source software is also garbage.

      Though, one of the big downsides of more community driven projects is that they tend to be riddled with bugs, and likely just as many security issues. The “obvious” easy to reproduce bugs and issues tends to be ironed out in excessively short order, but the one in a million bug due to the code having some unstable mode of operation isn’t usually fixed. A more organized program development would however constrain itself to not have such modes of operation. (Like the other day I crashed blender by pressing a key that isn’t mapped to anything, it should have done nothing, but it decided to close the program without saving. And no, I haven’t been able to reproduce that bug.)

      In my own experience, no side is actually better. They are both just different sides of the same coin, the question has always been “money or time, what do you value less?” when it comes to choosing between open source or closed source solutions to a problem. Sometimes it might actually be easier to make one’s own code.

      I though do think open source is a decent solution for more “universal” software that will be a dependency to other software, this is usually in the form of various libraries, APIs, etc. (I however consider Libraries and APIs as “tools”, the toolmaker doesn’t own the house I built with it. Ie, GPL and other viral copy-left licenses isn’t my cup of tea in some situations.)

      1. I’ve run into just as many bugs in closed source as open…but at least in open I can load up the debugger and trace what my issue is, fix it, and submit it back to the original project and hopefully make it better.

        With the closed source, when the original dev says they are done, whatever bugs are there will be for basically forever

  3. Looks like they custom designed a MIPS OOT decompiler to go though the assembly looking for functions. It was semiautomatic so a human still had to tell it if it made the right match. Some stuff had to be done manually particularly the more ticky bits. First decompiler I ever seen that produced useable code, probably alot of human fixing up. Here’s a link where the team that pull this off explains oot decompilation.

  4. If I am paying for it, the source code should be included with my purchase. I do not think it would be that hard to legally bind the customer to keep the source private.

    This allows it to be open source and closed source. You could provide patches for the source code without distributing the software itself.

    1. It only has to be leaked once to become widely available, and for companies without well funded legal teams, the “legally binding” stuff is toothless.

      If an IP owner is OK with the source code being widely available, they usually skip the please-don’t-share stage and go straight to open source.

      There are exceptions, for example Microsoft shares a subset of Windows source code with some partner organizations… but they very obviously have the means to hold leakers accountable.

  5. Linking to the MVG video? Pathetic.

    Every one of MVG’s videos about various decompilations is wrong. Not just “incorrect” style wrong, but “liar, liar, pants on fire”-type wrong.

    He constantly throws around the term “clean-room”, which none of these decompiles are. He even makes the utterly baffling assertion that Nintendo can’t issue takedown requests over this OoT decompilation, when nothing could be further from the truth. Most decompiles of N64 games were at least done from scratch, with the authors of the decompilation having to come up with their own function names and so on.

    Meanwhile, the OoT decompile makes use of various function names that were found in the symbol table that was inadvertently shipped on the Ocarina: Master Quest bonus disc that was available for the GameCube, where Nintendo released an emulated version of the game alongside Wind Waker. The fact that the developers of this decompiled version are using variable and function names from that .map file makes it MORE likely, not LESS likely, that Nintendo could take legal action.

    Shame on MVG for his piss-poor take, and shame on HaD for using it in this article.

    1. To my knowledge, just “decompiling” code isn’t cleanroom to start with in any regard.

      To clarify for other readers.
      “Clean room” practices is when one describes how the code works, and then someone else makes a new code from scratch that achieves the same function based on the description given. This is a fairly labor intensive task.

      Just translating machine code or the like into other more descriptive language is generally regarded to be the same work of art.

      To a degree the same “clean room” practice can be applied to books.
      If one takes a book and just translates it into another language, then it is legally the same book. (Though, the translator has a copyright on the translation, but the original author(s) still have the copyright over the contents of the book.)
      While if one describes the book’s contents and have someone else write a similar one, then it isn’t the same book. (although plagiarism is likely.)

      Not that an actual “clean room” approach is always legally okay, there is many pitfalls for one to stumble down.

      One of the biggest things a lot of people though forget is that a project isn’t just code. Art assets have their own copyright. Here one doesn’t have to go much beyond resemblance in most cases for it to be directly infringing. So cleanroom practices isn’t a silver bullet, if the game looks the same and especially plays the same, then from an artwork perspective it is the same game even if its code isn’t in itself infringing.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.