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

131–140 of 190 posts

Re: Decompiling a Nintendo 64 game in 84 days

#131

Post by protocolture »

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 "Ok, seeing as you dont know if you own the game, could you give us permission just in case you do"

Company A: "No, we would need to review the records. However if you released the game to market, we would check just to see if we can sue"

Nightdive has an identical conversation with Company B, who may have bought the rights from Company A but only have archival records.

Nightdive walks away from the project.

Re: Decompiling a Nintendo 64 game in 84 days

#132

Post by bakugo »

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…

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

Re: Decompiling a Nintendo 64 game in 84 days

#133

Post by unknownfuture »

DSMan195276 wrote: post #108
qarl2 wrote: post #84

Earlier quoted context omitted.

Really though? You have to try really hard to make your code that unstable - and well written code isn't that. Seems more like voodoo.

Who said games were well written? Older games are often very sloppy and buggy, and abuse the specific hardware they're designed for to get extra performance, unique graphical effects, etc. Emulators constantly run into games that don't run because of specific hardware nuances that may or may not have been intentionally used (Ex. relying on exact cycle counts, reading uninitialized memory, changing values while they'r…

I wouldn't characterize that as sloppy or buggy in any way (though certainly that is also true for some games). Exploiting hardware in new and novel ways was an essential part of developing for older consoles.

This is something someone only familiar with writing code for general purpose devices or higher level languages can't imagine. But when you're building for one very specific hardware platform you can tailor your code to that platform in ways that simply aren't possible when building for portability.

Re: Decompiling a Nintendo 64 game in 84 days

#134

Post by inigyou »

agiacalone wrote: post #66
VCFundedGenYer wrote: post #31

Earlier quoted context omitted.

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

When I was in high school, graphing calculators were pretty new. New enough that most teachers had not yet encountered them. I was a pretty nerdy kid even then, and I saw graphing calculator as 'portable computer' in 1993! So, of course I wanted one. When our teachers found about them, they banned the use of graphing calculators, some teachers going so far as to only allowing 'four-bangers' (a basic one) for classes…

Imagine if year 2 kids get a calculator instead of learning to add. They'll never learn to add.

Re: Decompiling a Nintendo 64 game in 84 days

#135

Post by inigyou »

LPisGood wrote: post #65
VCFundedGenYer wrote: post #31

Earlier quoted context omitted.

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

Could you not say the same about using a compiler or higher level language or a library you don’t understand or an algorithm you don’t understand or a chip that you don’t understand?

Yes. How many JavaScript bootcamp programmers don't know how memory works?

Re: Decompiling a Nintendo 64 game in 84 days

#136

Post by S-E-P »

jonhohle wrote: post #109
Sesse__ wrote: post #46

Earlier quoted context omitted.

> Historically there was a notion of "clean room" reimplementation These projects start off with the original assembly code and use it actively throughout all stages. This is about as far away from clean room as you get.

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.

Re: Decompiling a Nintendo 64 game in 84 days

#137

Post by ninjin »

thebruce87m wrote: post #18

Mildly related, but I have been waiting for goldeneye to be decompiled for a while but before that process has finished there is has been a spiritual successor(?) made that has scratched the single-player itch for me: https://store.steampowered.com/app/1574480/Agent_64_Spies_Ne... Worth a look if you want a bit of nostalgia.

If you are interested in the "sequel", Perfect Dark, then there is this PC port based on the decompilation project that plays great:

https://github.com/perfect-dark-pc-port/perfect_dark

Ported it to OpenBSD for fun an evening about a year ago.

Re: Decompiling a Nintendo 64 game in 84 days

#138

Post by bitwize »

bakugo wrote: post #132
bitwize wrote: post #116

Earlier quoted context omitted.

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…

> 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 produce software at industrial scales to meet industrial needs. And right now, there is no future for industrial-scale software development without AI. People and companies who refuse to use it will be lapped, in terms of speed, quality, and security, by those who do use it.

Re: Decompiling a Nintendo 64 game in 84 days

#139

Post by qingcharles »

rasz wrote: post #102
qingcharles wrote: post #80

Earlier quoted context omitted.

I just did one last weekend, but it is a game that was clearly written in assembler in the first place (Elite 8088 CGA). Trying to reconstruct the original build environment that Andy Onions (where are you?) used took some time. It was assembled with 16-bit MASM, but you can't easily run 16-bit exes under 64-bit Windows, so a bit of a kludge to set up DOSbox where the LLMs can push/pull in-and-out of it while being a…

>Making up plausible function names and branch labels was pretty quick for LLMs. there was official source code release for 6502 port, why not match names from that one?

It's a good idea, thank you. I hadn't thought of it. Assuming Andy Onions had access to the 6502 code to work from. It should be fairly trivial to figure out from the shape of the x86 code.

Re: Decompiling a Nintendo 64 game in 84 days

#140

Post by qarl2 »

DSMan195276 wrote: post #108
qarl2 wrote: post #84

Earlier quoted context omitted.

Really though? You have to try really hard to make your code that unstable - and well written code isn't that. Seems more like voodoo.

Who said games were well written? Older games are often very sloppy and buggy, and abuse the specific hardware they're designed for to get extra performance, unique graphical effects, etc. Emulators constantly run into games that don't run because of specific hardware nuances that may or may not have been intentionally used (Ex. relying on exact cycle counts, reading uninitialized memory, changing values while they'r…

Sure.

I guess I'm assuming that sloppy and buggy software didn't much become popular.

Because it was sloppy and buggy.

Post reply on HN