Live data from Hacker News

Decompiling a Nintendo 64 game in 84 days

blog.chrislewis.au

71–80 of 191 posts

Re: Decompiling a Nintendo 64 game in 84 days

#71

Earlier quoted context omitted.

If you can't see why your analogy is deeply broken I honestly don't know what to do for you.

It’s not clear to me why people believe determinism has some special property.

When you read the code thats been generated and submit it as a PR it becomes deterministic

Re: Decompiling a Nintendo 64 game in 84 days

#72

It's especially annoying that LLMs/agents are a logical starting point for decompiling old games but there is a significant backlash against it as the gaming community is very anti-AI and consumers of the benefits decompiling offers tend to be noncoders who don't believe that AI can do more than slop. I've seen takes such as "they're too lazy to learn C++" and accepting a PR from someone using Claude taints the proje…

I think the backlash isn’t necessarily against the decomp itself, but rather the sloppy/buggy PC ports that often come from it.

In my mind using an LLM to assist with decompiling is fine, as the output is provably correct. It either compiles to the original binary or it doesn’t.

Turning that into a playable PC game with controls that feel good, etc, is a different story. That requires human taste & judgement.

Re: Decompiling a Nintendo 64 game in 84 days

#73
post #42
post #23

What's the legal status of these? Historically there was a notion of "clean room" reimplementation. These days it seems people translate the actual game code into a different representation of that same code and that makes it open source? Github is full of these.

It seems like it could go either way to me in the US (not a lawyer, but someone who has a fair amount of experience in reverse engineering / fair use issues). On the one hand, it is fairly clear that producing source code with the explicit goal of reproducing a 1:1 binary is in no way transformative, so that's out. This would be a really hard argument to even attempt. On the other hand, these projects are mostly free…

> it is fairly clear that producing source code with the explicit goal of reproducing a 1:1 binary is in no way transformative, so that's out. This would be a really hard argument to even attempt.

Absolutely false. There are an infinite number of programs that will compile to the same machine code. Especially when an optimizer is involved. Discovering one of those is a creative process, transformative, and protected.

Using an LLM to do it for you? I wouldn’t touch that with a 10 foot pole. Seems too close to mechanical transformation to me.

Re: Decompiling a Nintendo 64 game in 84 days

#74
post #41

Earlier quoted context omitted.

Most of these projects carefully distribute only the source code representation of the binaries, for this reason, relying on the consumer to acquire / own the art assets and copyrighted material (logos, trademarks, etc.).

The code assets are just as copyright encumbered as the art assets.

None of the original source code exists in these projects. It’s all created from scratch.

Copyright for this new code is owned by the person doing decompilation. No one knows how similar to the original it is or not, just that it compiles to the same output.

Edit to clarify: by not exist, I mean it is not publicly available.

Re: Decompiling a Nintendo 64 game in 84 days

#75

Earlier quoted context omitted.

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

I use AI all the time for coding, but a tool that non-deterministically reaches potentially a different output than I would have produced myself is not analogous to typewriters.

You yourself would be non-deterministic if we could rewind time. So what's the issue here?

Not to mention, LLMs can be made deterministic if that were actually valuable.

Seems like determinism is just the latest excuse to hate.

Re: Decompiling a Nintendo 64 game in 84 days

#76
post #21

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.

[flagged]

Producing shit code slowly hasn't held me back so far and I don't intend to start letting it do so now.

Re: Decompiling a Nintendo 64 game in 84 days

#77
post #27

Earlier quoted context omitted.

Yes many games are caught up in IP hell. Including the one my username is inspired by. It's why you see a lot of fan remakes. Another sad side effect of corporate owned IP is also a lot of times the individuals who did the bulk of the work on something can't be the ones to do a remake. They don't own their own work. A company owns it. That's what most of us sign up for to get a paycheck. But when it's something like…

I think that we should change copyright law such that 1) Rights can't be held by corporations, only individuals. So the rights to a piece of art or IP would always trace down to a list of names. 2) Everything enters the public domain after 20 years or the death of the entire list of ownership.

Would you still allow transfer of copyrights? Otherwise 1) would really make things more difficult in this case, because you're gonna need to deal with far more people (and potentially far more complicated contracts to try to work around this problem). A shorter expiration period would definitely help, at the very least a 'use it or lose it' provision that would remove the protection from works that are no longer being sold.

Re: Decompiling a Nintendo 64 game in 84 days

#78

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?

[deleted]

Re: Decompiling a Nintendo 64 game in 84 days

#79

Earlier quoted context omitted.

The code assets are just as copyright encumbered as the art assets.

None of the original source code exists in these projects. It’s all created from scratch. Copyright for this new code is owned by the person doing decompilation. No one knows how similar to the original it is or not, just that it compiles to the same output. Edit to clarify: by not exist, I mean it is not publicly available.

It's not an obvious legal argument that it is not a derivative work of the compiled code or the original source code that produced that. Clean room reverse engineering is meant to give you a strong argument for that, and while it's not necessarily required to prevail against a copyright case (or actually sufficient) it's gonna make things harder if you don't. (All of this is made more murky because copyright is meant to only cover expressions of human creativity, and code is kind of a mix of creativity and mechanical details: the clean room approach is meant to separate out the mechanical details)

Also, If it is an unauthorized derivative work, as I understand it then it might not even qualify for copyright protection itself.

Re: Decompiling a Nintendo 64 game in 84 days

#80
post #57

For people who've done matching decomps: what burned the most calendar time for you, toolchain freeze or the last 5% of non-matching functions?

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 able to drive it enough to execute MASM and read the stderr and output files etc to get a feedback loop going.

Making up plausible function names and branch labels was pretty quick for LLMs.

Post reply on HN