Hacker News new | past | comments | ask | show | jobs | submit login
Super Mario 64 has been decompiled (gbatemp.net)
269 points by dimillian 10 days ago | hide | past | web | favorite | 89 comments

It should be also noted that the inner working of Super Mario 64 is already extremely well known due to numerous TAS attempts, so I found this manual decompilation hardly surprising. A recent video [1] detailing the "one-key" TAS [2] is mind-blowing.

[1] https://www.youtube.com/watch?v=wjge1bVobN0

[2] http://tasvideos.org/3264M.html

Also worth noting here is pannenkoek2012: https://www.youtube.com/user/pannenkoek2012 https://www.youtube.com/user/pannenkeok2012

His explanations are mind-blowing as well and fun to watch :)

It's also worth pointing to Kaze's videos for what dedication can bring even without the original source code. You'll find among other things recreations of later Mario games, or even games like Portal (and mechanics!) implemented in SM64. https://youtube.com/user/KazeBG0/videos

His wiki: https://mario64hacks.fandom.com/wiki/Kaze_Emanuar

Kaze Emanuar is part of the team that produced this decompilation.

Update: He has a (long!) Wikipedia article: https://en.wikipedia.org/wiki/Pannenkoek2012

The really mind-blowing thing here is how the real name of a guy with the handle 'pannenkoek2012' can be 'Scott Buchanan'.

Why? Everyone loves pancakes

Oddly enough, "pannekoek" makes me think of the political philosopher (of whom I'm a fan), though this is likely on account of me not speaking Dutch.

It just means "pancake".

A pannenkoek is not a pancake. A pannenkoek more closely resembles a thicker crepe.


I went to college with him, and I genuinely had no idea that it was him until several years afterwards. I definitely wish I had realized back when I had the chance to pick his brain about this sort of thing!

That video was way more complex and interesting than I thought it would be.

This is a good way to turn kids into hackers!

That has just broke me. Thanks :)

Interestingly, there exists other projects that aim to rebuild exact original ROM's. For example, Pokémon Ruby and Pokémon Emerald have been disassembled[1][2] and then slowly converted to C making sure that the hash of the ROM always stays the same.

[1] https://github.com/pret/pokeruby

[2] https://github.com/pret/pokeemerald

Shouldn't this be possible using some AI and/or brute force technique?

Given infinite time and computing power, yes.

Well given a set of known, used optimization techniques the backward operation would be possible to try. If it matches the target binary, would be one step closer to something considered source reconstruction.


You just need one :)


Can't forget that trailing slash :)

Wow. They recreated the source from the IDA output instructions. Holy shit.

From IDA's decompiled source, presumably, with manual tweaks to make it compile the same.

No, they did it by hand.

The team also had somewhat of an automated decompiler but it's really just a skeleton to get started from.


The game modding community never ceases to amaze me. I know of a few communities that are Reverse Engineering shockwave just to be able to retrieve original game code, and in some cases create private servers for defunct games.

Also theres a cool project archiving all Flash and Shockwave games called BlueMaximas Flashpoint. The people working on preserving these old games are amazing.

I do fear the death of some of those awesome NewGrounds games.

Absolutely mind boggling.


they did it by hand, creating code themselves from the mips output. in-sane!


Anyone know how much manual work was needed to do this? Did they just use a tool to generate the C code? The functions unhelpfully have names like func_802507AC.

It's in the third post or so. Apparently Nintendo didn't turn on any compiler optimizations so porting the mips assembly back to c and fiddling around a bit until the original compiler produced identical instructions again was a feasible thing to do.

That makes me wonder how much better we can make it perform by turning on optimizations (and likely fixing undefined behavior in places). There's quite a few locations in the game where the framerate and gameplay suffer.

My unfounded suspicion is that optimizations might have been turned off to avoid bugs in the toolchain. The developers would have had to deal with very early versions of these tools before the comsole was launched and in development itself.

It was one of the first games and easily outclassed by later releases so I'm sure there are many optimizations that could be made.

I hope we get the same with Waverace one day, nothing since has matched the feel of the wave physics in that one, it would be interesting to see what they did.

One of the “first games”?

What on earth do you mean?

One of the first games released on the N64 system.


From context he likely means the first games for the platform.

I vaguely remember it was a launch title.

Some people need everything explained don't they? "What do you mean first game? I distinctly remember playing tag at school and that preceded Wave Race 64 by at least 2 years. Please stop spreading FUD".

Perhaps but it is easy to forget that sometimes they simply either don't understand or that English may not be their primary language.

I try to assume that such things are genuine questions unless facetiousness is obvious.

Makes for a more pleasant place that way.

It's crazy how ambitious it was to have Mario 64 as a launch title, particularly when you compare it with the other launch title, Pilotwings 64.

Apparently some later releases of SM64 turned on optimizations and have less lag than the earlier ones.

This is cool but seems to be "just" the output from IDA with the functions renamed in the output? If that's the case I'm wondering why we don't see this sort of thing more often (other than the effort required of course)

>It's not an ordinary decompilation generated by IDA. They actually rewrote all the functions from reading MIPS assembly and compiled it with the original compiler, adjusting the code until it produced identical output to a vanilla ROM.

Reverse engineering a reproducible build is quite a bit more than "just" output.

What more is needed?

A perfect decompiler would just do it, but writing the exact inverse of a compilation tool chain would be... Difficult. You would have to have a different decompiler for each version each tiny little difference.

These guys were capable of figuring out and naming what every function did and then rewriting each of them over and over and over to get the original tool chain to output bit for bit the exact same binary as they started with.

Something like taking x-rays of an unknown machine and being able to recreate perfect pixel replicas of the engineering drawings or listening to a piece of music and being able to exactly write out the score.

There goes the old say: "that would be impossible just like attempting to get the original cow by putting together ten thousand hamburgers".

Sounds like a job for a genetic algorithm or machine learning.

I'd recommend watching this CppCon talk [1] about compiler optioning. It isn't just that recompilation is hard, or that it is difficult for humans to do. At a fundamental level, the information is not there at all, because the compiler can make very impressive optimizations. Machine learning can deal with weak signals, but it can't deal with no signal.

[1] https://www.youtube.com/watch?v=nLv_INgaLq8

There has been similar things done in the past, for example for Dune Legacy (Dune II) or REminiscence (Flashback)

Mario 64 is more recent so might be a magnitude more complex.

There are also other approaches, like a total re-implementation, not a decompile/re-source. ScummVM engine for Blade Runner, the adventure game from 90's is a recent very impressive example of that

I can’t believe ScummVM has re-implemented 72 classic game engines[1] from scratch. They also document their basic revere-engineering strategies[2].

[1] https://github.com/scummvm/scummvm/tree/master/engines

[2] https://wiki.scummvm.org/index.php?title=HOWTO-Reverse_Engin...

the `src` folder seems to contain the reverse-engineered C code. Most of the assembly-only files left look to me like they are just describing data.

They mention in the thread that the binary seemed to have been compiled without optimisation, which means it's a lot easier to translate back to source than most games would be.

Best day in pannenkoek's life

His video on the Rolling Rocks 0.5 A press clear is one of the most informative and entertaining technical videos I've ever watched.

I had never heard of the guy before watching that video, but I gleaned from the comments that there was something about it turning into a meme, and turning the guy off from making more commentated vidoes? If so, that's a real shame, because I could watch content from him all day long.

He used this in one of his videos a few months ago...

Surprising that an unoptimized build could be fast enough to not be noticed.

Their toolchain might not have been mature enough at that point for the compiler to optimize reliably. Just means they had to optimize it manually.

The SDK used the compiler from the IDO 5.3 package which was provided by SGI for developing in IRIX 5.3 (if you paid the extra for that option).

I think by then it would have already been pretty mature.

Nintendo freak out in 3, 2, 1...

Freak out on something that is not widely publicly available? How so?

Well the code is out there now, and I'm sure many have a copy.

It made it to r/datahoarders and I'm sure the eye will have a copy.

There's no way we're letting this slip. If anybody can't find a copy PM me and I'll help you track one down.

Alternatively, there's a mirror here at the moment. https://anonfile.com/D5rcz5u4n6/sm64_zip

I imagine it'll get taken down eventually, but I don't see a problem with letting as many people get their eyes on it in the meantime.

What I mean is that Nintendo is going to DMCA that link, but it's fine, we've got other copies.

In situations like this I highly recommend anyone with a spare 15.2MB of disk space to download this just to help preserve it.

Yeah can't post on 4chan without a VPN, should've used 8ch.

/tech/ would love this

I mean, that's just Nintendo being Nintendo. You know they will freak out over the silliest stuff when it comes to their Mario franchise, it's just a given. Maybe these folks should have decompiled some "orphaned" code/game where we literally have no idea who the copyright owner even is, then at least it would bring the stuff back from obscurity. But Mario 64 is just 'meh'.

What are you talking about? Super Mario 64 is an extremely loved game and is still played. People will find much more interest in this than some obscure game that nobody cares about.

People are passionate about this game and there is a good chance of a PC port of the game now (as well as more substantial mods) because of that.

From some brief research, a developer reported they're only 60% of the way there and the audio system hasn't been decompiled yet.

No, 60% is just about renaming the functions.

In this leak, there's still a fair bit of decomp work to be done on the audio systems.

Otherwise, you are right: the majority of the work left is to document the functions, to organize the code so that it's easy to mod and play around with, and to provide high level documentation on the systems/how the decomp was made. You wouldn't want anyone to think that all you have to do to decomp something is to run a binary through IDA, right?

Plus, there are more released versions of SM64, and who knows what's in there?

The build is reproducible (provides the same binary output as the original), so the remaining work is to rename the function to make it easier to understand.

Every link that leads to this file is shady af haha smh

its cool and all, but i've seen this before with other games and what happens is the people that want to do game development and people that want muck around with old decompiled source code are two different camps of people so I wouldn't expect much

Yeah, the end result of this isn't even opensource. Nintendo is still the owner of the code that was decompiled. This is why the people working on the project didn't want it be leaked in the first place, because nintendo will try to shutdown the project before its done.

The result is often a classic game running on a modern system without needing to jump through hoops, which is a huge win to people who enjoy playing the game in question.

OpenTTD, OpenRCT2, and OpenMW all come to mind, not to mention the many ports of Id games.

OpenTTD and al are clean room implementation of the original engines, not reverse-engineered ones. That's massively different legally speaking.

They are reimplementations but sadly far from clean room. The ASM was often referenced and even used side by side as the projects migrated to their own code base.

It's really a matter of how badly the community wants it I think.

AFAIK the n64 emulators don't have any real issues with SM64, this seems more useful for easier rom hacks

Emulators require much more resources than a native game.

True, but in perspective a decent N64 emulator requires less than a modern web browser. Though admittedly that's a really low bar.

It would be cool to get SM64 running at fullspeed on something like an older Rasberry Pi, which I think should be feasible now.

I also wonder if you could add stuff like raytracing given the original source. (Obv not on the Pi)

That should be feasible even with emulation. My memory seems to be a bit faulty, but IIRC UltraHLE could run SM64 at full speed on systems with less than 1GB and 1Ghz.

I can't remember if it was full speed but it was perfectly playable to emulate SM64 with UltraHLE on my Pentium 200MMX OC to 225MHz with a Voodoo 2 8MB and 96MB of RAM.

I had to run it in Windows NT5 beta though, it stuttered in Windows 95.

I agree. Still, it would be a nice 'code golf' style project to do on weekends or rainy days.

You guys remember mario.com on MS-DOS? A full clone of Super Mario running fullspeed on DOS?

Can you guys imagine mario64.exe? ^^

The Raspberry Pi 1 and 2 are slower than 1 Ghz, and ARM has less IPC than x86 (although I'm admittedly not sure about 90s-era x86).

OpenMW has no code from MW, it's a reimplementation. It doesn't use any of MW's code, and doesn't try to.

Technically, yes, you could use a decompiled game code to port the game to another platform, but the legalities are not in your favor.

Mario 64 has some great mechanics though..a gamedev could want to use the exact mechanics in their own game.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact