Duke Nukem: Zero Hour N64 Rom Reverse-Engineering Project Hits 100%
Posted3 months agoActive3 months ago
github.comTechstoryHigh profile
excitedpositive
Debate
20/100
Reverse-EngineeringGamingN64
Key topics
Reverse-Engineering
Gaming
N64
The Duke Nukem: Zero Hour N64 ROM reverse-engineering project has reached 100% completion, sparking discussion about the motivations behind such projects and potential future developments like ports.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
1h
Peak period
20
9-12h
Avg / period
8.4
Comment distribution101 data points
Loading chart...
Based on 101 loaded comments
Key moments
- 01Story posted
Oct 19, 2025 at 4:54 PM EDT
3 months ago
Step 01 - 02First comment
Oct 19, 2025 at 6:17 PM EDT
1h after posting
Step 02 - 03Peak activity
20 comments in 9-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 21, 2025 at 4:12 PM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45637880Type: storyLast synced: 11/20/2025, 6:27:41 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Note: To use this repository, you must already own a copy of the game."
The Readme is too technical and misses a writeup on the soul of the project: Section 1, title. Section 2, already talking about Ubuntu and dependencies. Where is section "Why?" :-) ?
- https://github.com/ajxs/yamaha_dx7_rom_disassembly
- https://github.com/ajxs/yamaha_dx9_rom_disassembly
It started because I was just curious about how these devices actually worked. In the end I learned a lot of really invaluable skills that really broadened my horizons as an engineer. I got a chance to talk to a handful of incredibly smart people too. The actual work can be a lot of fun. It's like piecing together a really large and technical jigsaw puzzle. In my case, it also led to me being able to release a fun firmware mod: https://github.com/ajxs/yamaha_dx97
In case anyone is curious about how I worked, I wrote a bit of a tutorial article: https://ajxs.me/blog/Introduction_to_Reverse-Engineering_Vin...
It can be a bit analogous to archaeology too. Even though in my case the DX7 is only 42 years old, that was an aeon ago in computing terms. You gain a bit of insight into how different engineers used to design and build things. Even though development for the N64 is fairly recent, from memory the console had some interesting constraints that made development tricky.
The ones that come to mind are the tiny 4KB texture cache, high memory latency (thanks Rambus), and inefficient RCP microcode. The N64 could have been so much more with a few architectural tweaks but developers liked the Playstation much better on account of its simplicity despite it being technically inferior in most respects.
That statement is surprising, as being a kid I remember the PlayStation as obviously graphically superior. I’m not doubting you but what explains the difference between technical and user perception?
I've no doubt (as a thoroughly amateur video game historian) that with a few small tweaks Nintendo would have ate Sony's lunch that generation. In that alternate universe Sega would have had better developer support for the Saturn and done crazy stuff with their super-wacky architecture too but I digress...
It also sounds crazy that games like tekken 3 could run on 3mb RAM total, when just the current music track feels like it could take that much space.
I too have a beloved video game from my childhood: Mega Man Battle Network 2. That game changed my life. I learned English and became a programmer because of it. I have two physical copies of it in my collection, one of them factory sealed.
Sometimes I open the game in IDA and try to reverse engineer bits and pieces of it. I just want to understand the game. I don't have the time, the dedication or even the low level programming knowledge that these badass folks in the ROM hacking community have, but I still try it.
https://github.com/smitelli/cosmore
https://cosmodoc.org/
Doing it long enough requires learning compiler history and theory, understanding business and engineering pressures of making the game, and occasionally reveals why parts of the game work the way they do.
I stream working on SotN and am happy to answer any questions in chat if you’re interested in learning more - https://m.twitch.tv/madeupofwires/home
It's an interesting challenge, you can improve it or make it do X,Y,Z, you can add speedrunning or competition gaming features, solving puzzles gives a sense of accomplishment, a certain small group gives you social clout, etc.
also, a lot of things in stuff like ROMs is about I/O to component in the devices, so you can disassemble and decompile all you want but without the right specifications and context you cannot say what the code does.
so it will also need all specifications of the hardware platform you are running the code on, as well as in this case perhaps even hardware in the catridge etc. (heard those also sometimes have their own chips etc...).
i'd say for 'regular application code' that runs within an OS it might be easier, but still you need to provide a lot of context from the actual execution environment to reason properly what the code actually does? (what does INT 80 run and possibly return anyway, that code is outside of your target binary)
There are several scientific publications on this. But I don't think the latest models are available as convenient plugins for IDA or Ghidra. Guessing variable and function names are considered as relatively easy nowadays. Types and structures are the challenges now.
It’s possible you could set it off on the labelling task, but anecdotally in my experience it will fail when you need to look a couple levels deep into the code to see how functions play with each other. And again, imo, the big risk is getting a label that _looks_ right, but is actually pretty misleadingly wrong.
If it's easy to generate documentation, and / or if documentation is autogenerated, people are also less likely to actually read it. Worse, if that comment is then used with another LLM to generate code, it could do it even wronger.
I think that at this stage, all of the programming best practices will find a new reasoning, LLMs - that is, a well-documented API will have better results when an LLM takes a swing at it than a poorly documented one. Same with code and programming languages, use straightforward, non-magic code for better results. This was always true of course, but for some reason people have pushed that into the background or think of it as a box ticking exercise.
It’s a lot easier to have someone who knows the code well review a paragraph of text than to ask them to write that paragraph.
Good comments make the code much easier for LLMs to use, as well. Especially in the case where the LLM generated docs would be subtly misunderstanding the purpose.
As with any LLM output, of course it won't be 100% perfect, and you shouldn't treat the output as truthful "data". But I could absolutely use it to make sense of things that at first sight were gibberish, with the original next to it.
I don't think that's what they did. Looking at some gameplay footage on youtube, it's a third person game with a full 3d player model, not flat sprites, and the level geometry seems to be full proper 3d without the build engine distortions when looking up and down. I think they built or used a different engine designed to take advantage of the N64s graphics hardware.
Something around that, they used the build engine as a starting point but "hacked it to oblivion". On the very least it reuses the same level editor (maps are vanilla build editor compatible) and it does keep many of the old bugs, like "killer doors".
semi random source: https://forums.duke4.net/topic/9513-release-zero-hour-resour...
incidentally the predecessor "duke nukem 64" is already more akin to what gzdoom is by using polygons instead of 2.5 rendering for walls and floors and they decided to push for polygons in the actors too for "zero hour" release.
perhaps with a bit of luck you'd get some useful markers / functions mapped tho, its not unheard of.
problem in my mind (didnt test it ofc) would be that the decompiled version is decompiled from a different ISA that build usually compiles to, so the decompiled version in my mind would look totally different. (you dont have the ported sources i suppose, only the originals).
I'd argue that copyright should not be affected by the tools being used. If the project would've been compliant with copyright (ala, fair use) had it used human hands, then using an ai tool makes zero difference.
Getting the exact same binary is definitely something else. Figuring out the exact compiler version and options, libraries, etc. is itself nontrivial.
The Legend of Zelda: Twilight Princess has been getting farther along as well https://decomp.dev/zeldaret/tp
https://github.com/Xeeynamo/sotn-decomp
There are so many cool things that have been built for this decomp, probably my favorite being the dups tool (tools/dups) for finding duplicate or near duplicate code.
There are attempts like this https://github.com/louisgthier/decompai that are related, but not quite the same as this project.
Edit: just gave it a go, and guessing reasonable variable names works extremely well when there's partial information already available. Especially nice for things like naming all the counters and temporaries when you know what you're iterating over (so it's just boring manual and trivial work), but can also figure out the meaning of larger patterns for function names.
I might be misunderstanding what you mean, but there is decomp-permuter which I think does just this. Rewrites the code in various heuristics and subtle ways to attempt to find a match at function level.
https://github.com/simonlindholm/decomp-permuter
They are also downright superhuman at recognizing common library functions or spotting well known algorithms, even if badly mangled by compilation and decompilation.
But given how much of RE is just going into unfamiliar places and learning unfamiliar things? And how much of it is repetitive but-not-easy-to-automate tasks? I fully expect LLMs to proliferate.
It would be easy to argue LLMs are producing derivative, non-transformative works. AI companies have not made that any easier by paying publishers huge royalties to license training data.
I personally would stay away from it to avoid the risk, but I’d imagine if it became “easy” enough to produce a matching decomp with an LLM, we would get a more specific legal precedent pretty quickly.
..since how long? I've lost track (:
There are no Matrix movie sequels I hear you say? ... Indeed.
Functionally, the README describes that providing a game copy is necessary for creating a build. This would make sense, since unless the sound, image, text, etc. assets are all baked into the code, those would have to come separately.
Legally, it further doesn't make much sense. This is cleaned up (?) and painstakingly bytematched decompiler output (again based on the README), so it's unfortunately just plain illegal [0], disclaimers nonwithstanding.
[0] as always, legality depends on jurisdiction - so as always, if in doubt, consult an actual lawyer
People decompiling are not publishing binary blobs. They’re painstakingly writing C code that has never existed before. They own the copyright to that new, original, creative work.
If you own a copy of the game you can use that source code to rebuild a bit-perfect version of the game. Again, fair use. If you don’t own a copy of the game, you can produce binaries that are not bit perfect and are distinct from the original.
The painting analogy doesn’t quite work. To force it, though, decompiling is like writing instructions to reproduce a painting perfectly, but leaving out the tools and pigments. If you own the painting, the instructions will tell you how to figure out the tools and pigments, and you can recreate your personal copy, which was already your fair use right as an owner. If you don’t own the painting, you can use the instructions to create something new and unique. The instructions are not a copy of the painting, it’s a list of steps that is a distinct, creative, transformative work.
It matters with patents where you can have patented stuff in the source code without a problem as long as it's not compiled into the binary. Users who are unaffected by the patents or have a license can compile it in.
Fair use is used during a trial to determine if your use case is an OK exception despite being it a copyright infringment. It's not guaranteed to go into your favor (there are a lot of nuances case by case despite of precedents) and you need to be sued to exercise it.
What you can do is to mimic the behavior and look from scratch, then it would be a separate work. The internal structure would be quite different too. Even the same logic would most likely be coded differently. And the look wouldn't be pixel-perfect just very similar looking.
This is mostly for _interoperability_ and _never_ as a way to sidestep copyright entirely. At most, you are able to redistribute the portion that is minimally indispensable for interoperability, and _not the entire friggin program_. That would completely defeat the point of copyright. And _even_ when you do this for interoperability, you have to walk a very tight rope (e.g. cleanroom as discussed by the sibling comment, albeit clean room is actually not necessary in many jurisdictions), but obviously _nothing_ of this applies if you're just going to distribute the entire program, interoperability be damned, which you simply _cannot_ do (clean room or not).
Otherwise, what is this legal precedent you are talking about?
N.B. I have dedicated a significant chunk of my professional career to reverse engineer (competitor's) industrial software: file formats, protocols, interfaces, the lot.
> People decompiling are not publishing binary blobs. They’re painstakingly writing C code that has never existed before. They own the copyright to that new, original, creative work.
Nah. You're looking at the original binary in one screen and writing code on the other one _to implement the same game_. Just by that, it would already be a pretty much straightforward copyright violation.
But there's more! By your own admission, it even compiles to the same binary. This is a process (decompilation) that can even be fully automated! What is the creative process here? You put fancier doodles on the margins and comments? You changed the variable and function names, like a freshman trying to hide the fact that his assignment is plagiarized from another student's? This is such a textbook violation of copyright I'm not even sure it would actually be worth to use as an example on a textbook.
What is next, if I get nuns to write out the binary in hexadecimal using a painstaking manual process (say knitting it on bed linen), then they can distribute the result and even use it to play the original game? I'm sure the knitting would be very original and creative!
For the record even if I was only looking at a gameplay video (not the binary!) while writing my "new C program", that would still be, very easy to argue, a copyright violation. How many Tetris clones have been shut down this way? Now imagine if you have something that produces bit-for-bit identical output, as you would from decompilation.
BTW which blog is giving out this often parroted non-sensical justification for violating copyright, since it's like the 3rd time I see it repeated here almost line by line? Then when Nintendo comes in and lawfully shuts down the repo, of course cue the crying.
TLDR:
legal: decomp -> write spec -> get it signed off -> pass it to someone else for implementation -> distribute
illegal: decomp -> clean up -> distribute
Immediately once they pulled the binary up in their decompiler of choice they were legally tainted and could no longer legally publish any related source code.
This is of course then debated, like everything. So all of this is to the extent I'm familiar with the topic.
Sure, you must, I guess, but is anyone really going to jail over this piece of ancient history? I find these disclaimers cute.
The recent Perfect Dark port was incredible and I hope this decomp gets the same treatment.