Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Decompiling a Nintendo 64 game in 84 days

blog.chrislewis.au

Post reply on HN
Print view View original

151–160 of 189 posts

Re: Decompiling a Nintendo 64 game in 84 days

#151

Post by shakna »

bitwize wrote: post #138
bakugo wrote: post #132

Earlier quoted context omitted.

> I'm a better programmer than most 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?

I am proud of my work, and I hate working with AI. 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…

> those who refuse to use it will be lapped, in terms of ... 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?

Re: Decompiling a Nintendo 64 game in 84 days

#152

Post by krystalgamer »

xyzsparetimexyz wrote: post #119
hombre_fatal wrote: post #2

It's pretty amazing what you can do when you embrace LLMs, figure out how to build one high-quality rigorous project with them, and then start working on more projects. You become a machine with your workflow, once again limited only by your time/energy, tokens, and your discretion on how to spend it.

matching decompilation is a verifiable target. Its hard to create slop that still matches. The same does not hold up for coding with llms normally.

you can create slop that matches, they're called "fake matches". it's basically when you coerce the compiler to output what you want and then the source looks unrecognizable.

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

Re: Decompiling a Nintendo 64 game in 84 days

#153

Post by 4thguy »

protocolture wrote: post #131
amjnsx wrote: post #6

I’m surprised the game companies themselves aren’t interested in these projects. 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?

>Are their hands tied by legal or what other factors are preventing this? 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 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 "…

Looking up Nightdive Studios is how I discover that Thief: TDP is getting a remaster. Worth it

Re: Decompiling a Nintendo 64 game in 84 days

#154

Post by whatsakandr »

krystalgamer wrote: post #152
xyzsparetimexyz wrote: post #119

Earlier quoted context omitted.

matching decompilation is a verifiable target. Its hard to create slop that still matches. The same does not hold up for coding with llms normally.

you can create slop that matches, they're called "fake matches". it's basically when you coerce the compiler to output what you want and then the source looks unrecognizable. 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...

As a C++ dev, that operator delete looks like something I would see in prod.

Re: Decompiling a Nintendo 64 game in 84 days

#155

Post by tmountain »

SmasherEpilepti wrote: post #105
onlyrealcuzzo wrote: post #49

Earlier quoted context omitted.

Using typewriters is surrender! Not your handwriting, not your work!

That's a terrible analogy. It's more like using a typewriter where the job is calligraphy. 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…

There are lots of ways to have a fully functional brain besides writing code manually…

Re: Decompiling a Nintendo 64 game in 84 days

#156

Post by matheusmoreira »

shrx wrote: post #150
matheusmoreira wrote: post #87

Earlier quoted context omitted.

Loving this trend too. It inspired me to use AI to decompile my favorite games as well, mostly Mega Man Battle Network games from my childhood. I'm not going to make it in 84 days though. I insist on understanding the game and documenting it myself instead of just having the AI do it all for me on autopilot. As slow as that is, it's already led to some awesome moments. AI built a literal synthesizer that played back…

Can you describe with a bit more detail how you're approaching the BIOS reverse engineering?

I just grabbed my laptop's BIOS packages and told Claude and now Sol to statically analyze them. By now it's at around 80% done. Some stuff needs hardware validation, but the AIs were quite capable of doing most of the grueling work on their own. I'm having them reduce the problem as much as possible so I only have to deal with the hardware verification.

I'll also ask the AI to reverse engineer the LattePanda Mu BIOS later since I want to use the Mu on my handheld cyberdeck project. Nearly out of usage for the week, sadly. Wish Tibo would push his reset button yet again.

Re: Decompiling a Nintendo 64 game in 84 days

#157

Post by chollida1 »

VCFundedGenYer wrote: post #31
bitwize wrote: post #21

Earlier quoted context omitted.

[flagged]

Using AI is cognitive surrender. It's not your code, it's not your work.

What about writing in C. If you use a compiler its not your code that's running and not your work.

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?

Re: Decompiling a Nintendo 64 game in 84 days

#158

Post by circuit10 »

S-E-P wrote: post #136
jonhohle wrote: post #109

Earlier quoted context omitted.

These projects do not start with assembly. They start with machine code interleaved with data. Even getting to assembly through a disassembled requires some input and understanding. Usually these are raw binaries with no (or limited) metadata. When run through a disassembler, in most cases, it’s probably the first time anyone has ever looked at the assembly (assuming PlayStation or newer). There are no comments or la…

The term "original assembly code" is sufficient enough to communicate that the binaries that are being reversed are what is disclosed to the public intentionally. Their comment still stands; whether it's machine code or "original assembly code" that shipped on the disk it falls under "clean room" reversing and by extension implementation.

Being available to the public if they bought the game doesn't mean it's in the public domain and you're allowed to upload a copy of it (or a derivative work) onto GitHub, though

(I like these projects but I really don't think they could defend themselves legally if you company went after them)

Re: Decompiling a Nintendo 64 game in 84 days

#159

Post by dosisking »

bitwize wrote: post #116
bakugo wrote: post #56

Earlier quoted context omitted.

> You won't be able to produce as good code 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.

Username checks out. 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 ent…

> Do not judge the entire profession by Hackernews posters; most of us are in the upper quartile or so.

LOL

Re: Decompiling a Nintendo 64 game in 84 days

#160

Post by ndiddy »

bakugo wrote: post #58
minimaxir wrote: post #37

Earlier quoted context omitted.

Aside from Switch emulators which get C&D by Nintendo due to private key copyright infringement issues, nothing with existing emulators would cause a legal tussle. AI has zero impact on it.

> due to private key copyright infringement issues None of the Switch emulators Nintendo took down had such issues, they all required supplying your own keys. Nintendo takes them down anyway because they can, and because they have enough money that no individual can fight them on it. Their takedowns have no real legal standing, and there's no reason why they couldn't do the same for every other emulator, other than t…

Section 1201 of the DMCA makes it illegal in the US to defeat a technological measure that controls access to a copyrighted work (such as the Switch's game encryption) without the copyright owner's permission. It also makes it illegal to develop or distribute software that is primarily designed to defeat technological access control measures. Yuzu does not function without integrating the Switch's decryption keys without Nintendo's authorization, therefore under the DMCA it's an illegal piece of software. In general this means that any unauthorized emulator made for any relatively modern system is also illegal, since they all encrypt their games.

One thing to note is that all the famous legal cases establishing unauthorized emulation as legal revolved around PlayStation emulators. The PlayStation doesn't have anything that would be defined as a "technical measure" under the DMCA. The PlayStation copy protection involves stopping a user from playing a copied game on a real console, not stopping a user from making a copy of the game in the first place.

Post reply on HN