Decomp is out! …but what does that mean? – Ukikipedia News Week 10

Chances are if you are in any Mario 64 related Discord, you’ve seen the news- Decomp is on GitHub and available for public usage. But what is decomp? What does it actually do?

When programs are written, it is typically done in a high-level language like “C”, which is typically very legible to a human (if documented/labeled/named well). Machines can not read this code, however, as they only understand very basic instructions like “add these two values together” or “skip forward if this value is zero”. To turn our nice C code into something a machine can understand, we run it through a “compiler”. A compiler is a computer program that takes that C code and makes it into equivalent machine code so that it can be run by the machine. This machine code is what is present in a game cartridge or ROM, like Mario 64’s.

Programming directly in machine code is usually much more difficult than programming in a language like C for a variety of reasons. For one, C compilers strip out all function, variable, and file names, as well as comments; machines don’t need those to run the code, so they would take up unnecessary space. The code often points to hard-coded locations (called addresses), so shifting a ROM by inserting or removing lines of code would break the entire program. To prevent this, code must be removed to insert new code in its place, making additions often come at the cost of subtractions from the ROM. The machine code is also not meant to be legible by humans, so things are usually less clear than normal even with knowledge of the machine code. It can take a significant amount of work to understand long functions in machine code.

“Decomp” or the SM64 Decompilation attempts to go backward from the machine code to the original code by decompiling it, turning the machine code to C. This can restore the code to a state similar to the original and very generally allow things that would otherwise be very difficult or impossible with just the machine coded ROM. The SM64 decomp is special in that it is also “matching”- many decompilation projects simply aim for code that does the same thing as the original, but this project actually generates the exact same ROM using the original compiler Nintendo used. This goal ensures that the new code doesn’t have any logic mistakes caused by improper interpretation of the compiled code.

With the understanding of decomp, what can we really do? What limitations does it have? Some of the most common questions/points are answered here.

• Will this let us solve the TTC upwarp? Decomp is a powerful tool for finding glitches, but it is not a free bug solver/finder. Finding glitches in the code still takes a careful eye and can easily be missed. So far, no definite leads for the Upwarp have been found and it is impossible to say if there will.
• Was decomp produced by a decompiler? For the most part, no. All decompilation was done by hand by writing C, compiling it with the compiler, then comparing the machine code with the original ROM. Sometimes this is easy, sometimes this is hard. A decompiler was written particularly for the project called “MIPS-to-C”, but it primarily acts as a starting point for these C code guesses. The reason why a decompiler like Ghidra was not just used is simple- decompilers are designed to produce equivalent code, not matching code as described earlier.
• What can decomp do that earlier hacking could not? In a lot of situations, things that can be accomplished with decomp could already be done with normal ROM hacking. Decomp does allow improving the compiler to have less lag, something practically impossible prior. This can also end up with more compact ROMs, allowing larger ROM hacks in general. The largest upside for the casual hacker is simply just being able to understand the code, as normal hacking generally requires good notes on the game to do so effectively, while labeled/documented C tells you what it does in the code itself.
• Can this be ported to other platforms? Is anyone working on that? Decomp is a very good start to such a project and definitely makes this a possibility. However, it’s still not easy. The closest anyone has gotten is Wafel, an SM64 simulator meant for TASing that was created and developed by bad_boot. It contains all the game’s logic ported to PC, however, it is not meant to be a traditional native port. A full port would require work on both a graphical plug-in and audio plug-in, a task that is not yet taken on by any programmers.
• Has decomp found any notable glitches/bugs? Decomp has assisted in a handful of discoveries/techs within the game. Some notable discoveries found with the help of decomp:
  • Spiny Adoption (which allows turning a bob-omb into a butterfly, among other things)
  • Tess Turning (a TAS tech where using smaller joystick magnitudes is better)
  • Solving the BBH shadow crash (it references a NULL floor)
  • The black burn particles from fire/lava are a corrupted graphic
  • Koopa’s pink shorts are a corrupted light source
  • Ukikispeedia (a glitch that gives Ukiki hyperspeed)
  • Ride Cloning (a method of indirectly interacting with an object)
• …where’s Luigi at? Legitimately, everywhere. All over the repository are unused arrays the have a Mario object as the first element of the array and an unused second slot. There are switches in some places depending on the player, but only contain references to Mario. Luigi was definitely in the game at some point and his shadows are all over the place. However, he can certainly not be recovered from the current code the codebase has.

If you want to find out more about decomp, you can join the Discord here or check out the GitHub here. Hopefully this article gives you a start to understanding decomp and perhaps even working with decomp.

In other news

• superdavo0001 released a full TAS of Super Mario and the Cursed Castle. Check it out!
• Weegee completed 70 Star in 47:37, a time which put him in third place. Congrats to Weegee!
• In task 15 of the TAS Competition, the legendary combo of Dargos and SilentSlayers took first place, over Bretaigne and Ceeszee in second and Rush57 and fifdspence in third. Congratulations to the entire group and looking forward to the next task results!
• Super Mario Star Road, for the first time ever, runs on console! Kaze and a team of people worked to identify a number of bugs and crashes, all of which were fixed to allow for the hack to finally be console compatible.