Skip to content(if available)orjump to list(if available)

Duke Nukem: Zero Hour N64 ROM Reverse-Engineering Project Hits 100%

viraptor

It's 100% decompiled to C, but not fully labelled yet. That means there's lots it's auto-generated names all over the place. It would be interesting to see someone try to port it now though.

nomilk

Would LLMs be good at labelling, or would the risk of false-positives just waste more time than it saved?

viraptor

I wish someone ran a proper study. In my experience it helps mark some patterns you may not be immediately familiar with, like CRC functions/tables. It also does a good job where no thinking is required, like when you have partial information: "for(unk=0; unk<unk2; unk++) { unk3=players[unk]... }" - you know what the names are, you just need to do the boring part. For completely unknown things, it may get more interesting. But I know I'd like to at least see the suggestions. It's a long and boring work to decompile things fully.

zamadatix

Gillou68310 looks to have been a one person army for 99% of it, what an impressive show of dedication.

The Legend of Zelda: Twilight Princess has been getting farther along as well https://decomp.dev/zeldaret/tp

icu

Would really like to know what makes a person (or group of people) invest the time and energy to do this? Is there a group of hobbyist gamers who work on titles they love? Is it about digital conservation?

ajxs

I've spent a lot of time reverse-engineering vintage synthesizer firmware (which is a bit simpler than modern games). I did complete end-to-end annotations of these two vintage synth ROMs:

- 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.

jbverschoor

I guess you’ve never kicked ass and chewed bubble gum

zamadatix

In addition to those categories, speedrunning glitch hunters tend to gravitate to participating in these projects as well. E.g. the Twilight Princess decomp was started primarily by and for the speedrunning community.

jsheard

It's also the endgame for romhacking, once a game is fully decompiled modders can go far beyond what was feasible through prodding the original binary. That can mean much more complicated gameplay mods, but also porting the engine to run natively on modern platforms, removing framerate limits, and so on.

colechristensen

You climb a mountain because it's there. Different people have different mountains.

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.

j1elo

Same. Is there a project page or anything that explains the context, the reasons, the history behind this? I bet it would be very interesting.

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?" :-) ?

GranPC

Based off the commit history, this has been one person's on-off project for 3 years. My guess is that they like this game and they were curious about how decomps come to fruition - and what better way to find out than to do it?

TruffleLabs

"A decompilation of Duke Nukem Zero Hour for N64.

Note: To use this repository, you must already own a copy of the game."

reader9274

We all now do, of course

janwl

Usually these projects only contain a copy of the source code to build the binary. You still need the game assets like the levels and sounds to play the game.

reassess_blind

Are LLMs well suited to this kind of reverse engineering?

viraptor

You can definitely do a lot of relabeling that way. It may be also worth trying a loop of "fix until it matches binary" for separate files... But I haven't seen anyone actually write it up.

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.

ACCount37

Fairly well. They aren't perfect, but they save a lot of time.

They are also downright superhuman at recognizing common library functions or spotting well known algorithms, even if badly mangled by compilation and decompilation.

cactusplant7374

I'm using an agent to port a game. I have the source. It's not going well. Lots of rabbit holes that are self-inflicted because the LLM doesn't want to port a lot of libraries because it's too much work for one round. It does a lot of stubbing and makes assumptions and that breaks the whole thing.

hsbauauvhabzb

I’ve not experimented but I thought they might be valuable for isolated variable / function renaming

metadat

Still [eagerly] waiting over here for Duke Nuke Forever!

..since how long? I've lost track (: