HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
n64decomp
sm64
C2019–2024
n64decomp / sm64

sm64

A Super Mario 64 decompilation, brought to you by a bunch of clever folks.

Explore on GitHubRead Hacker News discussions
21Distinct people
23Mentions
0Explicit recommenders
9KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A Super Mario 64 decompilation, brought to you by a bunch of clever folks.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year23 dated mentions

Observed mentions: 2019-08-25 12:42:05 UTC to 2024-04-18 14:54:33 UTC.

02462019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 5 mentions; 3 submissions, 2 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2024

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC532
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC202
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC413
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC606
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC303
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC303

What Hacker News says

23 sources
coldpie·Apr 18, 2024
I agree with your concern, but I'm quite happy to see what's going on in the retro emulation & decompilation/reverse-engineering scenes[1]. A lot of that is being done and is driven by "the kids". It's an appealing, easy, and low-risk entry point for newer developers who want to dive into low level stuff, and it even has a bit of a "fuck the man" bent to it, which is fantastic. You're right that the environment is different from what we grew up with, it was always going to be. But I think the kids will find their own way. [1] If you haven't been tuned in, check this out, it's the goddamn Super Mario 64 source code in C, reverse-engineered from the game ROM: https://github.com/n64decomp/sm64/blob/master/src/game/hud.c Similar projects exist for a ton of other classic games. It's jaw dropping what they're doing out there.
In Halo 2 in HD: Pushing the Original Xbox to the Limit
xurukefi·Jan 13, 2024
Fascinating work. I know that people did the same for Super Mario 64 [1]. It is still unbelievable to me that they can generate a bit-by-bit identical copy of the original ROM by simply running some old gcc on actual C source code files. IIRC the main insight was that Nintendo did not use any optimization flags which made it possible to create a 100% matching binary. I've never really looked into it, but I guess the did some try and error to figure out the exact gcc version that Nintendo used to make sure that they get 100% identical binary code? [1] https://github.com/n64decomp/sm64
In Decompilation of Paper Mario for N64
phoboslab·Oct 21, 2023
Romhacks are typically modifying the compiled binary ROM image. Kaze' work is based on the painstakingly disassembled code from the n64decomp project[1]. He's working in C, modifying the game and compiling it again for the original hardware. Not sure I'd call that a "romhack". Great videos though! [1] https://github.com/n64decomp/sm64
In FPGA N64
derefr·Dec 16, 2022
It sounds like, rather than a ground-up rewrite, COBOL should be treated as an object-code language, and "hand-decompiled" (ala efforts like https://github.com/n64decomp/sm64) into an HLL that can, at every point, be losslessly transpiled back into the original COBOL. I know the tooling for doing that doesn't currently exist... but paying someone to develop it would be cheaper than any one of these ground-up rewrite projects!
In How popular is COBOL?
parkertomatoes·Dec 6, 2022
All nostalgia aside, TIL that superfans reverse engineered "Space Cadet" from binary code [1] the same way they did Mario 64 [2]. Not only that, they've ported the result to use SDL and execute in the browser under Emscripten. A super-impressive technical accomplishment with a beautifully tangible result, wow! My favorite bit - the reverse engineering process seems to have fixed the 64-bit bug Raymond Chen blogged about [3] > I did not find it, decompiled game worked in x64 mode on the first try. > It was either lost in decompilation or introduced in x64 port/not present in x86 build. > Based on public description of the bug (no ball collision), I guess that the bug was in TEdgeManager::TestGridBox [1] https://github.com/k4zmu2a/SpaceCadetPinball. [2] https://github.com/n64decomp/sm64 [3] https://devblogs.microsoft.com/oldnewthing/202201
Read the rest
06-00/?p=10...
In Play Windows Pinball (Space Cadet) on the Web
holmium·Apr 21, 2022
> The level of snark here is outstanding. [...] 'smelling the grass' I thought his snark wasn't too off the charts in this video. I'd bet it's more a cultural thing. If you were working on the N64, you're probably like two decades above Kaze's target audience for his youtube videos haha. Like, he said that you can either be a weirdo who spends all day optimizing nearly 30 year old source code, or someone who "touches grass"[1]. He, of course, was referencing his own lack of life, not Nintendo's programmers. But, you'd have to pretty familiar with current online memes and insults to get his joke. > I have not seen the Mario 64 source but I imagine some of the lowest level code was written in mips assembly but has been decompiled into C. No, we only decompiled C code back into C code. The decompilation matches 1 to 1 with the released ROM i
Read the rest
mages.[2] iirc, the only, non-libultra ASM code was the decompressor[3]. The C code was pretty obvious due to "wonders" of IDO -O0 optimization. We were forced to get surprisingly close to what Nintendo wrote. We were stuck with an `f32 [3]` 3-vec instead of a `struct`... > I suspect the debug flags in gameplay code were to avoid compiler bugs. As far as we could tell, this wasn't an issue. IDO 5.3 had no issues that we could find when compiling at -O2, but then again it was decompiled code. I personally subscribe to the '-O2 -g' IDO meme, but Giles Goddard thought it was out of fear of the unknown. So, I'd trust him. We had the `mulmul` patch for IDO. I don't know the chronology for the release of that patch to devs, though. We also haven't been able to find any N64s that have the mulmul issue. > An NTSC tv runs at 60Hz, you either hit 60fps or 30fps, anything in-between results in horrible tearing of the screen or your frames bounce between 60 and 30 and movement feels horrific. I wonder what Kaze is doing. I know that there was work on a variable framerate mod/revamp for SM64. I'd guess it'd be outputting at the N64's 60 fps mode with duplicated frames, but you'd have much better luck asking one of the modders/coders who were working on that a couple years ago. ---------- [1] which is Twitter's insult du jour: https://knowyourmeme.com/memes/touch-grass [2] https://github.com/n64decomp/sm64 [3] https://github.com/n64decomp/sm64/blob/master/asm/decompress...
In Overhauling Mario 64's code to reach 30 FPS and render 6x faster on N64 [video]
nebula8804·Apr 20, 2022
From what I understand he used Mario 64 decomp code. The game was reverse engineered as 1-1 compilable to the original rom. [1]:https://github.com/n64decomp/sm64 Fun fact: The people who did this moved on to Zelda 64 Ocarina of time and recently completed that project as well [2]:https://zelda64.dev/ There are ongoing projects by other people for Mario Kart 64, Goldeneye, Perfect-Dark, Banjo-Kazooie and others although I think the next target for completion may probably be either Majora's Mask or The Minish Cap.
In Overhauling Mario 64's code to reach 30 FPS and render 6x faster on N64 [video]
derefr·Feb 12, 2022
Before reading the paper: is "verified lifting" kind of like "deterministic decompilation" — where you ensure, with every modification to the generated HLL source, that it continues to compile back into the original LL object code? (See e.g. the Mario 64 decompilation — https://github.com/n64decomp/sm64 — , whose reverse-engineering process at all times kept a source tree that could build the original byte-identical ROMs of the games, despite being increasingly [manually] rewritten in an HLL.)
In A new programming language for high-performance computers
zamadatix·Nov 27, 2021
re3/revc is going to court largely because they included assets in their repository and advertised derivative works/ports. zret purposefully avoided all of these points making this oot mq decomp. Of course Nintendo can submit a case if they like but it'd be a lot less likely to enter an actual trial like re3/revc. A better comparison would be https://github.com/n64decomp/sm64 which followed the exact same guidelines as this project. Nintendo chased after and DMCA'd many projects based on it but never the original project.
In Zelda 64 has been fully decompiled
derefr·Oct 10, 2021
From the SM64 decompilation (https://github.com/n64decomp/sm64) 's README: > This repo does not include all assets necessary for compiling the ROMs. A prior copy of the game is required to extract the assets. In other words, the repo only contains the reverse-engineered source code, not any reproductions of Nintendo's copyrighted or trademarked materials. You have to produce those infringing assets yourself—using tools they supply, yes; but also, crucially, by feeding in a copy of the game you already—presumably—have a private-use license for.
In Super Mario 64 has been ported to iOS

Showing the 15 most recent of 23 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.