Decompiling a Nintendo 64 game in 84 days

You become a machine with your workflow, once again limited only by your time/energy, tokens, and your discretion on how to spend it.

Indeed. But I think it's fair to say that just embracing LLMs is not enough.

Not your handwriting, not your work!

Not to mention, LLMs can be made deterministic if that were actually valuable.

Seems like determinism is just the latest excuse to hate.

There’s a reason why the top comments of HN blog posts whine about articles that are clearly written by AI. I use AI constantly as a coding agent, but I care deeply about the authenticity of the words I write intended for other human beings to be my own.

I hope you understand, by so glibly switching from "determinism" to "authenticity" you've just provided more evidence that this is just the latest excuse to hate.

But that aside - what happens in a couple years, when LLMs inevitably improve, and their writing is objectively superior to human writing? And people who just want to read well-written material won't care about the authenticity?

I suspect there will be another glib switch. Because the reality here is just that AI is hated. Full stop.

Think about the act of writing with a pen.

Now think about what a typewriter does in that context.

Now think about what an LLM does in that context.

Can you reason about how those are vastly different tools within the context of writing or communication, so much so that the comparison doesn't actually make any sense?

Hint: it has nothing to do with determinism. It has to do with the nature of the work itself and the role of the person doing it.

As an aside, this whole exchange really is just a perfect encapsulation of the outcome-focused versus process-focused individual.

The outcome-focused person sees words in a document and whether an LLM produced them or a human typed them is a distinction without a difference.

The process-focused person is utterly baffled that anyone could think those are in any way equivalent.

HEH. I just read your comment three times and I definitely don't get it. I think its entire point is to express outrage about not getting it, rather than actually explain it.

Bafflement? Certainly.

Maybe a little sadness at the lack of understanding of, or appreciation for, the creative process? Sure.

Outrage? Nah.

I only see that construction used condescendingly.

I for example, let the AI generate inbetween reports for a hobby project. These reports describe me how the project looks, stages, progress, etc.

I do know plenty about this particular project.

Also i wrote tons and tons of CRUD apps, do I really loose anything if that one quiz i did for learning, i don't understand in detail?

I use LLMs at work all the time, and it truly does feel like somebody else coding for me, and me reviewing, cleaning up, and asking for changes. It's really not my work, nor is it my code, but I'm still fine bringing it in.

I also don't use LLMs on my personal code done in my free time because I want my brain to still be fully functional in a few years.

I suspect that a lot of people who are going full hog on LLMs aren't actually making up the difference, and are simply offloading their thinking. I choose to not be one of those. I'll use them at work because they make me faster and most of the code is already not mine. It's a means to an end. My personal projects are for the fun and love of programming, not just to have some software in the end.

I was a pretty nerdy kid even then, and I saw graphing calculator as 'portable computer' in 1993! So, of course I wanted one.

When our teachers found about them, they banned the use of graphing calculators, some teachers going so far as to only allowing 'four-bangers' (a basic one) for classes lower than Trig (I never got to Calc in high school).

Funny, but your statement reminded me of what one of math teachers used to say: "If you use a graphing calculator, you aren't doing math." It seems really quaint today.

Throw in "and when the batteries in your calculator die, you'll need to know how to do it by hand!" for good measure. :-)

I jest...

Then he brought the graphing calculators in and had us plot graphs on those, compare them to our hand sketches, and set domain and range on the graph based on the critical points we found. He emphasized that doing the math beforehand let us use the graphing calculator effectively, and without knowing the math the calculator was useless.

Which sounds like the most sensible voices w.r.t. AI. At least for now. Six months ago I would not trust AI for any but rather menial tasks, but frontier models are able to do more and more of what I do every time I turn around. The TI-83 has been a fixed quantity in terms of capability since the 90s, and it never computed derivatives itself.

Same with AI. Having AI generate a for loop doesn't mean you understand the concept of a for loop. You can argue that it's a waste of time to learn about for loops because an AI can write one for you but that's a separate matter.

Another example is computer algebra systems like Mathematica. It would be self-sabotage to use them on your calculus homework, but they're indispensable to the working mathematician, physicist, or engineer, whose time is wasted doing routine calculations by hand.

I then spent way more time than what I would have spent without the plotter to figure out that a pole and a zero were located right next to eachother.

I had no idea if the teacher had done that on purpose, but it made enough of an impression on me that I still remember it.

The point of math exercises is usually not to get to solution as quickly as possible.

Downloading a bunch of open source libraries and putting together some project with a bunch of glue code also requires little thinking, but before AI no one really said that was "cognitive surrender". People even got pats on the back... for using other people's work to build something.

You are setting the bar way to high. We use LLM's for our coding and its most definitely our code and work. How would it be any different than a collogue writing code that you review and commit?

This says more about you than anything else. You weren't able to produce good code before AI, and you are not producing good code after AI.

You might be right. I'm a better programmer than most, but I'm nowhere near as good as I could be, and there is still so much I could learn and improve upon. But back when I was saying that "AI is better than most programmers", ~6 months ago, I figured people at my level were still somewhat safe, as the average programmer, even working professionally, is a shockingly low bar. Do not judge the entire profession by Hackernews posters; most of us are in the upper quartile or so.

These days, for small to medium-sized tasks, frontier LLMs are consistently well within that upper quartile. People at my level have a lot to be concerned about, as most of our day-to-day can be automated away. Sure, there's need for judgement and architectural discipline, but in most shops that's done by the people we used to make fun of in the 2000s, who sit in design review meetings and produce box-and-arrow diagrams, not code. Those are now the real bringers of value to a software development company or division.

At a bare minimum, it is irresponsible to ship code that has any sort of security requirement without using AI. Frontier models are able to discover zero days in minutes that would have taken months with human investigators, and if you're not auditing and red-teaming your own code with AI, someone else will use AI to pop it.

You are just not working to a professional standard in 2026 if you're not using AI.

I don't think so. If you were truly better than most, you'd be proud of your work, instead of trying to avoid doing it at all costs, while accusing others who don't do the same of "not working to a professional standard."

Can't write bad code if you don't write code at all, am I right?

But reality is what it is. The economics are what they are. And at the present time, writing code without LLM assistance is a mere handicraft, an idle pastime indulged in as a curiosity. It's like writing games in BASIC on the Commodore 64—no one is doing it anymore for serious stuff. Software engineering is the practice of formulating and implementing procedures to produce software at industrial scales to meet industrial needs. And right now, there is no future for industrial-scale software development without AI. People and companies who refuse to use it will be lapped, in terms of speed, quality, and security, by those who do use it.

I uh... I might have burst out laughing. Sorry, but do you really, seriously, believe the machine so fantastic that it is widely called "slop", produces amazing quality outputs?

So what that means is that you the software engineer need to be doing what you should have been doing all along: start with systems analysis, stepwise refine that into a program specification, then break that into tasks to give to your programmers to implement. Per PRIDE, the sadly forgotten but comprehensive common-sense information systems methodology, the analysis and specification phases should take up the bulk of the time on a project, with actual programming taking up 15% or less. LLMs can drive that time asymptotically towards zero for human developers. The specification is the deliverable. As a former boss of mine put it, you should be able to delete the entire source code repository and get functionally the exact same software back by running the spec through the LLM.

But you're working with a stochastic system. Even GPU matrix calculations are nondeterministic. It isn't possible, to the delete the entire source code and get exactly the same software back.

And any spec, that is specific and non-ambiguous enough to carefully construct the exact needs of each is... Well, that's code. Not a PBI, not an Epic. It's code.

LOL

LLMs still produce some of these, specially on C++ decomps.You can see it most often when calling the base class constructor/destructor. Here's an example: https://github.com/emoluvjd2/thps2-demo-decomp/blob/33d2c12b...

Disassembler output can relatively easily match original binary, I doubt anyone would consider it decompilation.

Let's say you add requirement of being higher abstraction language than assembly. You can translate the assembly code 1:1 with simple string substitions to C code which would provably replicate the behavior of program perfectly. I would consider that more of hard coded emulation, opposite of JIT like ahead of time code translation. Just because the intermediate langauge is higher level language than assembly doesn't automatically mean that the program text operates at higher level of abstraction than assembly.

I have seen plenty of decompilation projects where you start reading the code many functions contain nonsensical variable reuse (and name that match the register names), address calculations and memory casts and array calculations, arrays of function pointers, offsets within structures which strongly mirrors the assembly code.

The problem is that you can't draw a hard line how good do the variable/function names need to be so that it can be considered decompilation instead of hard coded emulation. It's hard to draw a line for how much of higher level language features you need to use to be considered decompilation. It's hard to define how logical the control flow needs to be. The line becomes blurrier by system programmers approaching it from the other side. Sometimes an extensively optimized code can contain a lot more manual memory mangling, index and offset calculations, manual unrolling than the language requires. So many C programs with homebrew systems of emulating virtual functions using structs of pointers. In such situations it's hard to tell if decompilation is incomplete or whether program was written that way from start.

Another possibility of junk decompilation (which perfectly compiles to byte identical copy of original executable) is program which depends on exact program layout in memory or undefined aspects of programming language. It would perfectly replicate original behavior on original hardware/compiler, but provide 0 insights in intended program behavior and fail miserably when attempting to modify the code or port it to different hardware/compiler. For example the "decompiled" code might intentionally peform out of bounds array access thus touching completely different variable or depend on fallthrough between functions lacking return statement.

Taking it to the extreme would be something like:

```

char data[] = {0x10, 0x12, 0xab, 0xcf, ...}; // bytes corresponding to majority of original program.

int main(){ ((void*())data)(); // cast the array to function pointer and execute it

} ```

It might behave exactly like original program, but that's junk decompilation.

You could add additional restriction that C program isn't allowed to exploit any undefined or machine specific behavior, but then there is very high chance that even original program wouldn't satisfy it.

Original program might also contain parts of it written in assembly for performance reasons or because that was only way to access certain hardware features. What does it mean for decompilation? Is decompiled code not allowed to use the same techniques. If decompiled code is allowed to have some pieces of assembly what stops it from using it for everything. There is no way of knowing precisely how much assembly the original program used.

Relatedly, https://github.com/perfect-dark-pc-port/perfect_dark forked from the above describes itself as “a work-in-progress port of the Perfect Dark decompilation to modern platforms”. Further: “The game is in a mostly functional state, with both singleplayer and split-screen multiplayer modes fully working. There are minor graphics- and gameplay-related issues, and possibly occasional crashes.”

Seems like easy money to just decompile a retro game, add some quality of life improvements and stick it on steam.

Are their hands tied by legal or what other factors are preventing this?

Yes.

Even if you're the owner of the game, the contracts for the voice actors, motion capture, models, etc. frequently define very narrow terms of usage. Defining the exact release platforms is common. Not to mention profit sharing if the actors or studios you're hiring are popular.

It's even worse for retro games. Many times the original rights holder went out of business, sold their rights, died, or something else that muddies the ownership chain.

Including the one my username is inspired by. It's why you see a lot of fan remakes. Another sad side effect of corporate owned IP is also a lot of times the individuals who did the bulk of the work on something can't be the ones to do a remake. They don't own their own work. A company owns it. That's what most of us sign up for to get a paycheck. But when it's something like film or games, the effect on artists or designers can be pretty depressing.

So yes, games are not unique in this way. I am hopeful in the optimistic future case where LLMs lead to lower barriers to entry, UBI, and so forth that copyright essentially disappears, or at the very least is severely reformed.

Many things should simply enter the public domain at a far more accelerated rate.

1) Rights can't be held by corporations, only individuals. So the rights to a piece of art or IP would always trace down to a list of names.

2) Everything enters the public domain after 20 years or the death of the entire list of ownership.

Isn't the current system setup around the idea that the company gets the rights, and in return the workers get a basically risk-free salary? Wouldn’t your proposal undo that, so then workers took on the risk of whether they got paid, based on whether the game ends up being profitable?

Then again Disney's old "vault" strategy would counter it, and Nintendo is already toying with it to sell through FOMO. How can it be this hard to make companies keep our digital culture available for sale? It's not even charity.

I don't disagree with the spirit of your argument. I'm just saying that my proposal would be a lot easier to put in practice than anything that hurts companies. The strength of the proposal is exactly that companies will mostly shrug while creating a very clear legal separation of what's "active copyright" and what's an "abandoned work".

By the way, this would also apply to the GPL (and other copyleft licenses).

Since I'm just pitching wild ideas on the Internet of course I have the freedom to make any suggestion I want, but I would like to live in a world where (a) no companies or rights owners are able to play bullshit games with gating access to art that can be reproduced at trivial cost and (b) we can consume all the art we want that's past its sell-by date. It's insane to me that we don't have free, legal databases of every work of art created before, say, 2006.

Nightdive studios has a few blog posts regarding this.

The problem apparently is that a lot of retro game IP changed hands when records were physical.

So Nightdive goes to Company A and says "Hey do you have the rights to <Game> or did you sell them"?

Company A says "You can pay us 50,000 dollars to check our records we are not sure."

Nightdive says "Ok, seeing as you dont know if you own the game, could you give us permission just in case you do"

Company A: "No, we would need to review the records. However if you released the game to market, we would check just to see if we can sue"

Nightdive has an identical conversation with Company B, who may have bought the rights from Company A but only have archival records.

Nightdive walks away from the project.

i think you agree that there is. but it should change your language about this idea of "consumers" and "benefits" - like this is the difference between making code and making a product. nobody NEEDS retro games. in my opinion, they aren't even that good! they are completely and utterly an aesthetic experience. the process IS the product.

Not to mention, there's a lot of stuff beyond an "aesthetic experience". Videogames have historical value, and they have relevancy at the very least as a testament of the state of the industry at any given point.

Legend of Dragoon, for example, integrated QTE-like controls in its attacks, even as a turn-based game. FFVIII, released the same year, implemented interaction in a somewhat similar way. These two are very early predecessors to mechanics Clair Obscur: Expedition 33 much more recently used. That has value.

If anyone wants to establish random conditions as to why they consider a work to be worthy or not, they may have those. But then they should keep them to themselves, rather than pretending people shouldn't care about something because of the way it was done. It's like the classic situation of someone complaining about how some open source project doesn't do something exactly in the way they like. I have nothing but contempt and despise for that sort of people, and it's a whole order of magnitude worse here, where the "problem" stems from their political stance, which nobody with a pulse should give a crap about.

[right hand emoji] "their political stance"... "they should keep them to themselves"

Which does kind of suck. Yeah, it's not nearly as cool to say "I prompted a probabilistic pile of tensors and it did the hard work for me", and I think it majorly adjusts how "impressive" projects are. There's no point pretending like decompiling a game by hand and using GPT-6.7 to do it are remotely comparable.

The suck-y part is that if you do the decomp with GPT-6.7 and produce, say, a PC port of an early 2000s console game, a large number of people will refuse to touch it and treat it as if you have committed a cardinal sin. Maybe that's justified? I dunno. It definitely goes beyond people just saying it isn't as fun.

Meanwhile so many westerners see LLMs as "stealing IP", it becomes a bit paradoxical where the lines get drawn.

Vibe-decomped projects are also… a different result.

A matching hand-decompile is useful in itself, but it also serves as a proxy for how well you understand the project; how good are the function and variable names, are the structures good, do you understand the entire flow. There are plenty of LLM-decompiles out there that just match but still every variable name is “unk14”, where every flow is total spaghetti instead of going back to something closer to what a human would have written, or even tons of __asm__ statements. The match stopped being a high-quality proxy metric for the quality of the project as a whole. (There are also LLM-assisted decompiles that are high-quality, but then usually with significant human input. And of course, you can try to ask the agent to clean up the resulting mess after you're done matching, assuming you have any tokens left.)

Of course, if you just want the binary back and collect Internet points, you don't care about any of this. But decompilation projects are often made for either a) understanding the game better (for speedruns, TASes, or just general explanation), or b) modifying it. And for both, it is much nicer to have source that is closer to the original.