I prefer 1080 as snowboarding games go. Though must admit some fondness for Cool Boarders and a selection of other lower quality games that few will admit to enjoying.
Decomp tools for N64 have had some breakthroughs even before AI. Now I imagine it's even better. If that facilitates folks geeking out with their favorite guilty pleasure then so be it!
I'm not sure "community" was always the reason, but we might be talking about different eras. Back in the late 90s and early 00s there were the pioneering scenes for modding, emulation, fan subs, remakes, etc. and it was all highly competitive.
I don't mean to shit on anyone's legacy, but it seemed more ego driven and like there was something to prove either personally or politically. It was cultural and maybe even spiritual. Anyone working on this stuff felt powerful. Nearly a century of broadcast media and being told what to do and how feel by people from far away was ending. Disassembly felt more like deconstruction. It didn't feel like love. It was hacking. There's a reason why one can still shout "hack the planet!" into a crowd of nerds and get them to instantly light up.
I'm not even saying all this as an old fart. Things just changed so fast since then. I'm in my 30s.
More I am just confused for why the game was chosen. SM64, Zelda OoT for example I could easily understand the community motivations behind decompiling. This not so much, which makes the whole endeavor even cooler.
If anyone needs a full list of these projects (which includes this one), there's a pretty good selection here:
Though these may have a few they missed:
https://readonlymemo.com/decompilation-projects-and-n64-reco...
https://github.com/CharlotteCross1998/awesome-game-decompila...
- Moon Lights 2: https://github.com/Armonte/ml2decomp
- F-15 Strike Eagle II: https://github.com/neuviemeporte/f15se2-re
I've also been in discussion with people working on decompilation projects which are private. I won't share details, but it includes both well-known games and recent games (as in, built with link time optimizations).
The decompilation community is quite decentralized, with lots of Discord servers specific to one platform or a series of games. In the case of Windows it's also heavily fragmented, as there is no equivalent to community-standard tooling like splat or dtk-decomp for that platform, although my Ghidra extension has carved itself a niche in it.
Whether the broader communities will accept any of my work remains to be seek given the heavy correlation to those communities and anti AI sentiment.
I've noticed the anti-AI sentiment is starting to die down. People are slowly realising that, along with the voluminous amounts of slop, there are others who have been able to leverage AI with much success.
I see that one for Burnout Paradise is in the works, but I would love one for Burnout Revenge.
Fundamentally, decompilation is not solving a technical problem most of the time (because the source already exists somewhere) but a social one (that the owner doesn't want to release it).
I've made a similar point in an earlier comment, but consider the following:
Even if the original sources leaked in a human-readable format, the original game was probably written in a mixture of the device-specific dialect of the Mips R3000 assembly used by the Nintendo 64, whatever in-house assembler macro routines SGI provided for the RSP game-specific microcode, and some C89 glue code in an IDE like Metrowerks Codewarrior 4, by a team of overworked japanese developers in a hurry.
We can safely assume that the final decompiled code is way more readable/usable than the original.
> We can safely assume that the final decompiled code is way more readable/usable than the original.
Have you looked at any rediscovered repositories lately?
It's a pretty daft assumption that the original source code wouldn't carry more value than the decompiled machine-generated "source code". And much more so.
Certainly from the game historian's perspective. Just think about it. Inline comments, logs, scraps of documents/notes, variable/function naming, scrapped files and artwork, engine code, etc. These things are essentially a time capsule treasure and a peek into the history of the game, no matter their state.
If you've seen any rediscovered source code releases of old software, e.g. 86-DOS, Prince of Persia, Command & Conquer, Little Big Adventure, even Apollo or any of the "the making of"-style game releases built around it (Karateka, Ninja Turles) you'd probably think differently. These are super interesting to dive into because they capture the thoughts and decisions of the developers at the time.
Here are also some interesting articles to showcase what that means: https://gamehistory.org/category/source-code/
Define easier? There is virtually no incentive for a game studio to release their original source code. Studios are running on already tight enough margins as it is with one lackluster release being enough to doom a company to oblivion.
Unless you have a method to completely reorient capitalism away from the idea of intellectual property then painstakingly reversing the C code from MIPS assembly will always be the easier path.
Remember too, that we are on Hacker News. Only a tiny sliver of the population, in some cases just one or two people, cares about the source code. Not worthwhile for a studio to release the code just to satisfy a couple of nerds. What is the upside? Unknown. Downsides? Numerous.
Almost all instances of source code being released have come from small studios or individuals who are ideologically motivated, and are otherwise independently successful. John Carmack / Id Software comes to mind.
Controversial opinion: I think the FOSS movement was a setback and distraction from attaining software freedom as well as giving an undeserved negative reputation to "reverse-engineering" in some areas. RMS had the right idea, but missed the mark when it came to practical application by focusing far too much on "source code". Other industries have long been making third-party parts by merely inspecting existing ones with measuring tools, and let's not forget the whole discipline of scientific research is largely what amounts to "reverse-engineering" the natural world. You don't need the original source code if you have good decompilers, and now LLMs to assist.
Decompiling a binary, finding what you need to change, and then patching precisely that piece, seems like a far more liberating process than getting the source code, figuring out how to build it in its entirety, and possibly changing more than only the piece you wanted to. Many years ago, I remember coming across a few Java utilities that were public-domain but not open-source, and the author explicitly told users that they were to use a Java decompiler to decompile, edit, and recompile if they wanted to make any changes.
Ideas aren’t scarce. Someone who reads a book, or looks at a picture, or makes use of a copy of software is not preventing other people from doing so. The idea that an idea can be restricted are given exclusive use to one particular party for any amount of time by law, is dystopic.
Copyright in its origin was a time limited adaptation of property to non material, creative works (not ideas, those are not copyrightable) and most derivates of it to incentive this effort. It's a compromise to combat the tragedy of the commons for the mutual benefit of the author and the general public.
Modern copyright has nothing to do with this and is indeed highly dystopic.
> You don't need the original source code if you have good decompilers, and now LLMs to assist.
Yes, you do. Decompiling and modifying a binary can be illegal itself under the DMCA in certain circumstances. But even if it is not, distributing the decompiled source is against copyright.
> Java utilities that were public-domain but not open-source
AFAIK Java is specifically easy to decompile when it is not further obfuscated. That is not true for many other languages. And while you can technically reverse engineer any language it does make modifying software and even finding out what it does fundamentally more difficult.
> far more liberating process than getting the source code, figuring out how to build it in its entirety, and possibly changing more than only the piece you wanted to.
It's certainly more liberating because there are more restrictions you have to liberate from in the first place. RMS argues that these restrictions should not exist in the first place. As for building being difficult, no free license requires the author to use a good and easy build procedure, but the GPL requires them to provide you all the tools required to build the software unless they are already readily available: "The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities."
...and so is going over the speed limit.
Practically? Who gives a flying fuck.
PC magazines in the late 80s and early 90s told people how to patch binaries to fix bugs or enhance functionality, with lists of offsets and bytes. Without distributing the original, so no copyright issues there. I don't think anyone tried to go after them because they'd be fighting the 1st Amendment.
The FSF succeeded at changing the mindset towards more collaboration.
I agree that this also allowed to divert efforts from research on reverse engineering tooling by reducing the needs.
But AI is game changer for reverse engineering, so no secrets will be hidden in binaries.
In a way, this is a merge of an alternate branch of history where RE would be more powerful.
HEY, it was a GREAT game, but GREATEST? COME ON, this ain't no goldeneye
Useful, but complements existing tooling & falls short on the hard part
I work on Ship of Harkinian. We're sering more vibed libultraship ports. Yet to see a real success
Like OP, I've learned at lot in this process. I have versions running in the browser now with a custom WebGPU rendering engine. Still lots of jank and vibes, but it's wild to see what models are capable of with the right tooling. (I've had Claude add extensions into Ghidra for Xbox/Wii specific instruction support)
Wild times we're living in. It's great for software preservation though!
[1] https://github.com/cdlewis/snowboardkids2-decomp/tree/main
I'm also really looking forward to trying the Dinosaur Planet decomp, because the prototype ROM from which it was derived has a tendency to crash the various libretro cores/N64 emulators I've tried.
Reverse engineering is (luckily) OK, but reproducing (or, well, releasing) the actual original code with the help of decompilation isn't really allowed, is it?
