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.
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.
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.
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).
The Legend of Zelda: Twilight Princess has been getting farther along as well https://decomp.dev/zeldaret/tp
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.
- 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.
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.
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.
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?" :-) ?
The recent Perfect Dark port was incredible and I hope this decomp gets the same treatment.
Note: To use this repository, you must already own a copy of the game."
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.
They are also downright superhuman at recognizing common library functions or spotting well known algorithms, even if badly mangled by compilation and decompilation.
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.
Sure, you must, I guess, but is anyone really going to jail over this piece of ancient history? I find these disclaimers cute.
..since how long? I've lost track (: