Rendered at 11:12:35 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
jmcgough 2 days ago [-]
I've been absolutely loving the decomp projects that have been coming out lately. Huge props to the writer for this, Snowboard Kids is a real gem.
I'd also encourage people to check out the Legend of Dragoon recomp [1]. It's a real labor of love that has breathed new life into a largely abandoned game. You can play it fully vanilla, or with improved graphics, fixes to cumbersome design choices, bugfixes, etc.
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 music straight out of the ROM. Mapped out all of the music that way. It was incredible.
Have neen reverse engineering my laptop's BIOS as well. AI is fully in charge of that one, and it's nearly done. Hopefully soon I'll have drivers and perhaps even coreboot.
shrx 1 days ago [-]
Can you describe with a bit more detail how you're approaching the BIOS reverse engineering?
matheusmoreira 23 hours ago [-]
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.
joquarky 15 hours ago [-]
This brings back fond memories of fiddling with programs using a Super Snapshot cartridge on my Commodore 64.
I remember one game had a crude speech synthesis and I discarded the game and persisted out the speech synthesis code independently as a separate program to play with arbitrary input.
cleak 1 days ago [-]
I love this trend as well. More than any other project or trend, it makes me feel optimistic about a future with AI and little or no slop.
I had hoped to someday make retro games for all major 80s and 90s consoles. I started with the Atari 2600 12 years ago[0], and planned to move to other 6502 family systems when I had time. I realized last year that AI could essentially do all of what I considered the hard parts and craft of retro game assembly, which felt like having the rug pulled out from me. Projects like this have really turned that around for me.
New tools just mean old things become easier and new things become the difficult (where I think the fun is), but solvable, frontier. This category of projects inspired me to pick back up an Ultima V decompilation project I started more than 10 years ago[1,2]. I'm looking forward to a world where all of my childhood games are cracked wide open for mods, ports, etc.
I had a lot of fun with Snowboard Kids. Not quite Diddy Kong Racing, but one of my favourite N64 racers.
2 days ago [-]
melony 2 days ago [-]
Any advances in emulators recently? I would love to see Nintendo get into a legal tussle with Big AI. Giant douche can fight turd sandwiches.
minimaxir 2 days ago [-]
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.
bakugo 2 days ago [-]
> 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 them simply not wanting to.
ndiddy 23 hours ago [-]
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.
hombre_fatal 2 days ago [-]
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.
xyzsparetimexyz 1 days ago [-]
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.
krystalgamer 1 days ago [-]
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.
As a C++ dev, that operator delete looks like something I would see in prod.
Karliss 22 hours ago [-]
Matching decompilation is a verifiable target that ensures feature parity but it says nothing about being reasonable non slop decompilation.
Disassembler output can relatively easily match original binary, I doubt anyone would consider it decompilation.
Let's say you add requirement of being higher abstraction language than assembly. You can translate the assembly code 1:1 with simple string substitions to C code which would provably replicate the behavior of program perfectly. I would consider that more of hard coded emulation, opposite of JIT like ahead of time code translation. Just because the intermediate langauge is higher level language than assembly doesn't automatically mean that the program text operates at higher level of abstraction than assembly.
I have seen plenty of decompilation projects where you start reading the code many functions contain nonsensical variable reuse (and name that match the register names), address calculations and memory casts and array calculations, arrays of function pointers, offsets within structures which strongly mirrors the assembly code.
The problem is that you can't draw a hard line how good do the variable/function names need to be so that it can be considered decompilation instead of hard coded emulation. It's hard to draw a line for how much of higher level language features you need to use to be considered decompilation. It's hard to define how logical the control flow needs to be. The line becomes blurrier by system programmers approaching it from the other side. Sometimes an extensively optimized code can contain a lot more manual memory mangling, index and offset calculations, manual unrolling than the language requires. So many C programs with homebrew systems of emulating virtual functions using structs of pointers. In such situations it's hard to tell if decompilation is incomplete or whether program was written that way from start.
Another possibility of junk decompilation (which perfectly compiles to byte identical copy of original executable) is program which depends on exact program layout in memory or undefined aspects of programming language. It would perfectly replicate original behavior on original hardware/compiler, but provide 0 insights in intended program behavior and fail miserably when attempting to modify the code or port it to different hardware/compiler. For example the "decompiled" code might intentionally peform out of bounds array access thus touching completely different variable or depend on fallthrough between functions lacking return statement.
Taking it to the extreme would be something like:
```
char data[] = {0x10, 0x12, 0xab, 0xcf, ...}; // bytes corresponding to majority of original program.
int main(){
((void*())data)(); // cast the array to function pointer and execute it
}
```
It might behave exactly like original program, but that's junk decompilation.
You could add additional restriction that C program isn't allowed to exploit any undefined or machine specific behavior, but then there is very high chance that even original program wouldn't satisfy it.
Original program might also contain parts of it written in assembly for performance reasons or because that was only way to access certain hardware features. What does it mean for decompilation? Is decompiled code not allowed to use the same techniques. If decompiled code is allowed to have some pieces of assembly what stops it from using it for everything. There is no way of knowing precisely how much assembly the original program used.
plastic-enjoyer 2 days ago [-]
> 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.
Indeed. But I think it's fair to say that just embracing LLMs is not enough.
hombre_fatal 2 days ago [-]
I'd consider embracing to include developing expertise in the tool.
bitwize 2 days ago [-]
[flagged]
VCFundedGenYer 2 days ago [-]
Using AI is cognitive surrender. It's not your code, it's not your work.
onlyrealcuzzo 2 days ago [-]
Using typewriters is surrender!
Not your handwriting, not your work!
some-guy 2 days ago [-]
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.
qarl2 2 days ago [-]
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.
some-guy 2 days ago [-]
It’s not exactly determinism, it’s authenticity. If we rewind time, of course the words would be different. It’s not relevant to my argument.
There’s a reason why the top comments of HN blog posts whine about articles that are clearly written by AI. I use AI constantly as a coding agent, but I care deeply about the authenticity of the words I write intended for other human beings to be my own.
qarl2 1 days ago [-]
> It’s not exactly determinism, it’s authenticity.
I hope you understand, by so glibly switching from "determinism" to "authenticity" you've just provided more evidence that this is just the latest excuse to hate.
But that aside - what happens in a couple years, when LLMs inevitably improve, and their writing is objectively superior to human writing? And people who just want to read well-written material won't care about the authenticity?
I suspect there will be another glib switch. Because the reality here is just that AI is hated. Full stop.
SmasherEpilepti 1 days ago [-]
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 functional in a few years.
tmountain 23 hours ago [-]
There are lots of ways to have a fully functional brain besides writing code manually…
SmasherEpilepti 21 hours ago [-]
Yes, and all of them involve exercising your mind regularly. I could let LLMs do my personal projects for me and then try to make up the difference with brain teasers, language learning, etc. I choose to exercise my mind because I still love programming, including writing my own code.
I suspect that a lot of people who are going full hog on LLMs aren't actually making up the difference, and are simply offloading their thinking. I choose to not be one of those. I'll use them at work because they make me faster and most of the code is already not mine. It's a means to an end. My personal projects are for the fun and love of programming, not just to have some software in the end.
cdelsolar 1 days ago [-]
I still use LLMs on personal code as well because I can build way more of it and I have way too many open source projects
bakugo 2 days ago [-]
I think it's pretty telling that the only response techbros have to that is some form of false equivalence, every single time.
unknownfuture 2 days ago [-]
If you can't see why your analogy is deeply broken I honestly don't know what to do for you.
Ahrgo 22 hours ago [-]
You don't know HOW someone is using AI.
I for example, let the AI generate inbetween reports for a hobby project. These reports describe me how the project looks, stages, progress, etc.
I do know plenty about this particular project.
Also i wrote tons and tons of CRUD apps, do I really loose anything if that one quiz i did for learning, i don't understand in detail?
unknownfuture 13 hours ago [-]
Yeah you're still missing the point.
A more appropriate analogy for what you just described might be writing vs ghost writing.
But it's certainly not handwriting vs typewriter.
Note: there's no implied value judgement here.
My point is that the analogy that LLMs are equivalent to typewriters is fundamentally broken. Using an LLM to create text, and writing using writing tools, are simply completely different activities that just happen to lead to (at least superficially) the same outcomes.
Similarly, downloading a vase and 3D printing it isn't the same as making pottery. Programming a knitting machine to make socks for you isn't knitting. Putting text on paper using a printer isn't calligraphy.
And I'd argue we're going to collectively conclude that assembling software systems using AI isn't coding.
Again: no value judgement. But life isn't always just about outcomes. Process does, in fact, matter, and I think it's important we maintain these distinctions.
It's genuinely amazing and baffling to me that a non-trivial number of people around here don't seem to grok that.
LPisGood 2 days ago [-]
It’s not clear to me why people believe determinism has some special property.
bad_haircut72 2 days ago [-]
When you read the code thats been generated and submit it as a PR it becomes deterministic
unknownfuture 2 days ago [-]
You still don't get it.
Think about the act of writing with a pen.
Now think about what a typewriter does in that context.
Now think about what an LLM does in that context.
Can you reason about how those are vastly different tools within the context of writing or communication, so much so that the comparison doesn't actually make any sense?
Hint: it has nothing to do with determinism. It has to do with the nature of the work itself and the role of the person doing it.
As an aside, this whole exchange really is just a perfect encapsulation of the outcome-focused versus process-focused individual.
The outcome-focused person sees words in a document and whether an LLM produced them or a human typed them is a distinction without a difference.
The process-focused person is utterly baffled that anyone could think those are in any way equivalent.
qarl2 2 days ago [-]
> You still don't get it.
HEH. I just read your comment three times and I definitely don't get it. I think its entire point is to express outrage about not getting it, rather than actually explain it.
unknownfuture 1 days ago [-]
Weird, I don't think any of my comments express outrage
Bafflement? Certainly.
Maybe a little sadness at the lack of understanding of, or appreciation for, the creative process? Sure.
Outrage? Nah.
qarl2 1 days ago [-]
I think it was your phrase starting with the word "Hint:".
I only see that construction used condescendingly.
unknownfuture 1 days ago [-]
Yup, fair point, totally valid criticism.
2 days ago [-]
agiacalone 2 days ago [-]
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 lower than Trig (I never got to Calc in high school).
Funny, but your statement reminded me of what one of math teachers used to say: "If you use a graphing calculator, you aren't doing math." It seems really quaint today.
sapphicsnail 1 days ago [-]
The smart reason graphing calculators are banned is because students are meant to be learning a concept. You don't learn how to graph to pass a test you take a test so you're pressured to learn how to graph.
Same with AI. Having AI generate a for loop doesn't mean you understand the concept of a for loop. You can argue that it's a waste of time to learn about for loops because an AI can write one for you but that's a separate matter.
fasterik 22 hours ago [-]
That's why we use different tools when teaching/learning something vs. doing real work.
Another example is computer algebra systems like Mathematica. It would be self-sabotage to use them on your calculus homework, but they're indispensable to the working mathematician, physicist, or engineer, whose time is wasted doing routine calculations by hand.
tverbeure 1 days ago [-]
I remember a homework where I had to graph some function. I decided use the plotting function of Lotus 1-2-3 for that. The plot worked fine, but didn’t make sense.
I then spent way more time than what I would have spent without the plotter to figure out that a pole and a zero were located right next to eachother.
I had no idea if the teacher had done that on purpose, but it made enough of an impression on me that I still remember it.
The point of math exercises is usually not to get to solution as quickly as possible.
teeray 1 days ago [-]
It’s more like cheating off your neighbor’s math test than using a calculator
nsxwolf 1 days ago [-]
If I hand you a math problem, and you point your camera at it and write down ChatGPT’s answer, you are definitely not doing math.
agiacalone 1 days ago [-]
"If I hand you a equation to solve, and you type in the numbers, hit enter on your programmatic calculator, and write down Texas Instruments' answer, you are definitely not dong math." <-- would have been my teachers' attitude too.
Throw in "and when the batteries in your calculator die, you'll need to know how to do it by hand!" for good measure. :-)
I jest...
tripzilch 1 hours ago [-]
Dude, maybe stop holding up your high school math teacher as some kind of arbiter of truth ...
If the math teacher is unaware of the difference between "math" and "arithmetic", what are you even talking about?
mysterydip 1 days ago [-]
I think the difference with the calculator analogies is a calculator just speeds up calculations you could do yourself (granted some very slowly). I can’t type in “sally has 35 apples, and wants to give an equal number to each of her 7 friends. how many apples does each get?” I have to know to do 35/7. But an ai will do that problem solving for me, with zero understanding on my part.
bitwize 1 days ago [-]
I took calc at around the same time. The teacher had us learn to sketch function graphs by hand the old fashioned way, by finding the derivative and looking for critical points, etc.
Then he brought the graphing calculators in and had us plot graphs on those, compare them to our hand sketches, and set domain and range on the graph based on the critical points we found. He emphasized that doing the math beforehand let us use the graphing calculator effectively, and without knowing the math the calculator was useless.
Which sounds like the most sensible voices w.r.t. AI. At least for now. Six months ago I would not trust AI for any but rather menial tasks, but frontier models are able to do more and more of what I do every time I turn around. The TI-83 has been a fixed quantity in terms of capability since the 90s, and it never computed derivatives itself.
inigyou 1 days ago [-]
Imagine if year 2 kids get a calculator instead of learning to add. They'll never learn to add.
chollida1 23 hours ago [-]
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?
nickysielicki 2 days ago [-]
Actually it is your code and it is your work.
CursedSilicon 2 days ago [-]
The legality around that has not yet been tested, so
iAMkenough 1 days ago [-]
In the same sense that hiring someone overseas to do your remote work job is submitting your code and your work.
940273292020 2 days ago [-]
Using automated looms or wearing textiles woven by it is cognitive surrender. It's not your fabric, it's not your work.
rasz 1 days ago [-]
its a decomp, it wasnt your code to begin with
deadbabe 1 days ago [-]
There's a time for cognition and a time for just moving quickly and getting shit done.
Downloading a bunch of open source libraries and putting together some project with a bunch of glue code also requires little thinking, but before AI no one really said that was "cognitive surrender". People even got pats on the back... for using other people's work to build something.
TuxSH 2 days ago [-]
IMO it's fine if you use it to review hand-written code. Vibe-coding (and especially 100% slop projects) on the other hand, is indeed cognitive surrender as it's identical to cheating on homework back then.
cdelsolar 1 days ago [-]
Yes it is
LPisGood 2 days ago [-]
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?
inigyou 1 days ago [-]
Yes. How many JavaScript bootcamp programmers don't know how memory works?
2 days ago [-]
tom_ 2 days ago [-]
Producing shit code slowly hasn't held me back so far and I don't intend to start letting it do so now.
bakugo 2 days ago [-]
> 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.
bitwize 1 days ago [-]
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 entire profession by Hackernews posters; most of us are in the upper quartile or so.
These days, for small to medium-sized tasks, frontier LLMs are consistently well within that upper quartile. People at my level have a lot to be concerned about, as most of our day-to-day can be automated away. Sure, there's need for judgement and architectural discipline, but in most shops that's done by the people we used to make fun of in the 2000s, who sit in design review meetings and produce box-and-arrow diagrams, not code. Those are now the real bringers of value to a software development company or division.
At a bare minimum, it is irresponsible to ship code that has any sort of security requirement without using AI. Frontier models are able to discover zero days in minutes that would have taken months with human investigators, and if you're not auditing and red-teaming your own code with AI, someone else will use AI to pop it.
You are just not working to a professional standard in 2026 if you're not using AI.
bakugo 1 days ago [-]
> 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?
bitwize 1 days ago [-]
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.
shakna 1 days ago [-]
> 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?
bitwize 22 hours ago [-]
My observations suggest that frontier models consistently produce correct, high-quality code for small to medium-sized tasks provided the goals are well-specified and testable. Even when they appear to get distracted, they converge on a solution.
So what that means is that you the software engineer need to be doing what you should have been doing all along: start with systems analysis, stepwise refine that into a program specification, then break that into tasks to give to your programmers to implement. Per PRIDE, the sadly forgotten but comprehensive common-sense information systems methodology, the analysis and specification phases should take up the bulk of the time on a project, with actual programming taking up 15% or less. LLMs can drive that time asymptotically towards zero for human developers. The specification is the deliverable. As a former boss of mine put it, you should be able to delete the entire source code repository and get functionally the exact same software back by running the spec through the LLM.
shakna 22 hours ago [-]
ITIL is at version 5 now - the idea of a process, is not exactly forgotten in the industry.
But you're working with a stochastic system. Even GPU matrix calculations are nondeterministic. It isn't possible, to the delete the entire source code and get exactly the same software back.
And any spec, that is specific and non-ambiguous enough to carefully construct the exact needs of each is... Well, that's code. Not a PBI, not an Epic. It's code.
bitwize 17 hours ago [-]
I said "functionally", not (as Claude says) "byte-identically".
shakna 14 hours ago [-]
I said Epic and PBI, not bytes. User Stories are ambiguous. Acceptance Criteria can be argued. And which path in our languages ambiguities that the model will follow, cannot be deterministic by the nature of our hardware.
If you produce a spec that is entirely unambiguous in every way, again, that's code. That's the purpose of a programming language - distilling from the natural ambiguities of natural language, to specificity.
senordevnyc 23 hours ago [-]
Oh honey, the next few years is going to be brutal for you.
shakna 22 hours ago [-]
Well, considering I accidentally embarrassed the Anthropic rep at work yesterday by producing better code in an hour, then he did in a day, I'm... Pretty sure I'm going to be safe.
senordevnyc 15 hours ago [-]
lol, I'm sure.
AlexeyBelov 2 hours ago [-]
Why are you so condescending? It would be better to write an actual argument instead of what you did.
dosisking 23 hours ago [-]
> Do not judge the entire profession by Hackernews posters; most of us are in the upper quartile or so.
LOL
senordevnyc 23 hours ago [-]
Imagine being so angry about LLMs that you feel the need to come on here and insult people. Seems so small and insecure.
amjnsx 2 days ago [-]
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?
Teknoman117 2 days ago [-]
> Are their hands tied by legal
Yes.
Even if you're the owner of the game, the contracts for the voice actors, motion capture, models, etc. frequently define very narrow terms of usage. Defining the exact release platforms is common. Not to mention profit sharing if the actors or studios you're hiring are popular.
It's even worse for retro games. Many times the original rights holder went out of business, sold their rights, died, or something else that muddies the ownership chain.
godwinson__4-8 2 days ago [-]
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 film or games, the effect on artists or designers can be pretty depressing.
So yes, games are not unique in this way. I am hopeful in the optimistic future case where LLMs lead to lower barriers to entry, UBI, and so forth that copyright essentially disappears, or at the very least is severely reformed.
Many things should simply enter the public domain at a far more accelerated rate.
quacked 2 days ago [-]
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.
no-name-here 2 days ago [-]
> 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.
Isn't the current system setup around the idea that the company gets the rights, and in return the workers get a basically risk-free salary? Wouldn’t your proposal undo that, so then workers took on the risk of whether they got paid, based on whether the game ends up being profitable?
quacked 1 days ago [-]
In theory, the financier or team of financiers would be added onto the list of creating individuals. I suppose some sort of fractional representation might be worked out.
rcxdude 2 days ago [-]
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.
quacked 1 days ago [-]
I would not. I'm far less concerned about the rights and profits of copyright holders and far more concerned with society and civilization having access to the art that's produced within it.
Since I'm just pitching wild ideas on the Internet of course I have the freedom to make any suggestion I want, but I would like to live in a world where (a) no companies or rights owners are able to play bullshit games with gating access to art that can be reproduced at trivial cost and (b) we can consume all the art we want that's past its sell-by date. It's insane to me that we don't have free, legal databases of every work of art created before, say, 2006.
rcxdude 22 hours ago [-]
I don't disagree with the goal, I'm just saying that having more copyright owners in a given work is likely to make the licensing more complicated and opaque, not less.
glimshe 2 days ago [-]
That would be a tough change... An easier one, which is how things used to be, that everything enters public domain IF not renewed after X years (let's say 20). Abandoned or complex IP would just become public domain unless the owners themselves figure things out and demonstrate interest with the renewal process. Even a modest fee would lead to a huge gain without much friction for the true rights holders.
debugnik 1 days ago [-]
Legal would remember to pay the fee for their abandoned works, just in case, while the rest of the company does nil with them. I'd rather address the issue directly and expire the copyright after X years since it was last published.
Then again Disney's old "vault" strategy would counter it, and Nintendo is already toying with it to sell through FOMO. How can it be this hard to make companies keep our digital culture available for sale? It's not even charity.
quacked 23 hours ago [-]
We'll do it ourselves! People are natural hoarders and archivists, as should be effortlessly proven by custom wikis.
glimshe 20 hours ago [-]
It's okay if Legal does that. The idea isn't to prevent companies from owning copyrighted works long-term, it's to prevent the waste of abandoned works. There are thousands, if not millions, of works that could be cleanly reused under my proposal.
I don't disagree with the spirit of your argument. I'm just saying that my proposal would be a lot easier to put in practice than anything that hurts companies. The strength of the proposal is exactly that companies will mostly shrug while creating a very clear legal separation of what's "active copyright" and what's an "abandoned work".
By the way, this would also apply to the GPL (and other copyleft licenses).
throwaway12053 1 days ago [-]
Alternatively a "use it or lose it" requirement that the company must use the IP in a significant way. Either by proving that the sales of the product is still significant (like GTA V) or provide a meaningful update within X years (unlike GTA 6)
Daz912 1 days ago [-]
[dead]
wombat-man 2 days ago [-]
I don't know how they made it, but there was a GoldenEye made for Xbox 360 that seems to only update the UI. The controls are maybe a little different, but you can swap between original and updated renderer in game. Anyway, they couldn't ship in the end due to legal stuff.
protocolture 1 days ago [-]
>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 <Game> 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.
4thguy 24 hours ago [-]
Looking up Nightdive Studios is how I discover that Thief: TDP is getting a remaster. Worth it
thebruce87m 2 days ago [-]
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.
ninjin 1 days ago [-]
If you are interested in the "sequel", Perfect Dark, then there is this PC port based on the decompilation project that plays great:
Ported it to OpenBSD for fun an evening about a year ago.
AndrewOMartin 1 days ago [-]
Not to mention the Standalone VR port (I tried it out last night). I played Goldeneye 64 to absolute death in single and multi player, and played Perfect Dark about once at a friends house, and I still had a wonderful nostalgic "childhood dream"-like experience.
I saw some news last week saying the project had reached 100%. Looking at the git repo (https://gitlab.com/kholdfuzion/goldeneye_src) that claim is a bit harder to verify, but maybe look again?
tigen 2 days ago [-]
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.
Sesse__ 2 days ago [-]
> 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.
jonhohle 1 days ago [-]
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 labels or symbols. Not what most people would consider “the original assembly”.
xyzsparetimexyz 1 days ago [-]
Ghidra is able to figure out the functions in around 99%++ of cases though
S-E-P 1 days ago [-]
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.
circuit10 23 hours ago [-]
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)
grishka 1 days ago [-]
There was a decompilation project of GTA 3 and Vice City. It got DMCAed by Rockstar Games, despite requiring the user to provide their own game assets.
bri3d 2 days ago [-]
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, intended for owners of the game to play the original game on a different platform or in a modified format, and not likely to have a negative effect on the original work's desirability or value. And, the reproductions aren't complete and alone usually produce limited to no value to a consumer (usually, they won't start without the original game files). These are the other important factors considered in fair use determinations and generally go the way of these being OK.
So, it's hard to say. With reverse engineering and copyright in the US in general, context is crucially important; something that would be completely illegal for one purpose (ie - decompiling and recompiling a competitor's software to distribute it without a license or use it internally without purchasing it would be obviously illegal) could be OK for another one.
ndriscoll 2 days ago [-]
In a sane world, if brought before a court, the binary itself wouldn't have any protection unless hand authored. The actual creative work/human expression was the source code. The entire point of compiling is to strip that extra data out, leaving pure functional logic that doesn't even strictly match the source logic thanks to optimization.
Then a freshly written project would be completely different with no derivative elements at all; the only commonality between the two codebases is their functional elements. You can compile a decomp into the same binary, but that's only to prove functional equivalence. The intended mode would be with a modern compiler that completely rewrites the logic (it might even have to if it writes it for a completely different computer architecture, which describes every retro console game). Then neither the source nor the compiled artifact would match.
bri3d 2 days ago [-]
> The entire point of compiling is to strip that extra data out, leaving pure functional logic that doesn't even strictly match the source logic thanks to optimization.
I strongly disagree with this notion from even a conceptual (much less legal) level; the point of compilation is not to erase the algorithms the programmer implemented, just to optimize and implement them.
> You can compile a decomp into the same binary, but that's only to prove functional equivalence.
This is like saying that a translated book is only "functionally" identical to the original; there's a lot of precedent in copyright law for this not being the case, and I don't think any argument revolving around the transformativeness of the compilation process would fly at all.
ndriscoll 1 days ago [-]
A huge portion of the actual thing I write when writing a program does not exist at all in the compiled binary. Names, types, type parameters, etc. being big ones, but many types are also aliases for the empty struct, so their value doesn't exist at runtime either. Conversely, I can write _.map(_.map(_.map(f))) and have that turn into all sorts of looping and branching logic that I didn't write, and the meaning of which is basically "do whatever must be done to make the types work".
Programs as written are nothing like programs as compiled, certainly not as an expressive endeavor. Books don't have an analog. There's no point where we strip all conceptual meaning from the book and leave only the procedural algorithms the semantics demand. There's no point where we replace all the individual words with autovectorized versions, or where we automatically delete impossible sentences, or remove every layer of abstraction that the programmer put in there exactly for the ability to convey ideas.
jonhohle 2 days ago [-]
> 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.
ipsod 2 days ago [-]
Clean room might get you past copyrighted code, but surely it won't get you past trademarks or copyrighted artistic work?
bri3d 2 days ago [-]
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.).
charcircuit 2 days ago [-]
The code assets are just as copyright encumbered as the art assets.
jonhohle 2 days ago [-]
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.
SmasherEpilepti 1 days ago [-]
A decompilation is not clean room, nor is it "created from scratch". If that was the case, you could just compile a program to remove the copyright, because the machine code doesn't resemble the source code at all either.
A reimplementation or a behavior-based clone is an entirely different legal world from decompilation.
jonhohle 1 days ago [-]
The compiled binary is protected and the property of the original company. The source code written by people doing decompilation is owned by the people doing the decompilation. That source code can compile to a lot of different binary representations, just like a lot of code representations (infinitely many) could compile to the original binary.
In fact, the goal of most decomp not to produce the same binary, that’s just used as a validation.
charcircuit 1 days ago [-]
>is owned by the people doing the decompilation
True, but as a derivative work of the original source code they don't have rights to do anything with that code without infringing copyright.
rcxdude 2 days ago [-]
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.
bri3d 2 days ago [-]
Yes, I agree with you (see my sibling post), but it's not what the post I replied to was saying.
charcircuit 2 days ago [-]
Historically these projects have gone to match byte for byte recreations which ensures that they are derivative works making them infringing copyright.
JLO64 2 days ago [-]
> One small but useful improvement was to give every task an explicit deadline and expose that deadline to the agent.
I’m really curious about trying this myself. Recently I’ve been handing off tasks for agents to complete on their own more and more. While their work is acceptable I’ve found them to not only take a long time to complete it, but they often add too much complexity and tests.
cpriest 2 days ago [-]
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?
qingcharles 2 days ago [-]
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.
rasz 1 days ago [-]
>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?
qingcharles 1 days ago [-]
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.
asiekierka 21 hours ago [-]
I had no issue with the toolchain, as I happened to work on a game (ZZT) whose toolchain of choice was documented by the author himself (well, he was off by one Turbo Pascal release). Lucky!
What took me the most time was actually the beginning: building a mental model of what assembly patterns map into which Pascal patterns, and finding good areas to start writing code from. In hindsight, I should have probably started by generating inline assembly equivalents of each procedure/function. The ending was relatively smooth sailing in comparison, but it is of course much easier if the compiler you're targeting doesn't do much in the way of optimization passes, so it's not representative of decompilation work for more modern targets.
globi 2 days ago [-]
LLMs are truly amazing and I hope those decomp will keep coming! I am currently watching the Test Drive Unlimited decompilation project, which seems to use a mix of LLM decomp and actual engine improvement (porting the game to Vulkan and a new physics engine instead of Havok):
https://github.com/opentestdriveunlimited/OpenTestDriveUnlim...
guardiangod 1 days ago [-]
Yeah I am decompiling a PS2 game. It's not easy but I think I finally have the right setup.
aap_ 21 hours ago [-]
Also been working on PS2 stuff. It's been very fun!
HDBaseT 1 days ago [-]
Sounds cool, please document your steps and pitfalls. I would live to try this one day.
jaydayvis 2 days ago [-]
I think Marx is rolling in his grave over the tirelessly expended human to recreate what almost definitely already exists on a floppy sitting in some “IP - Do Not Touch” lock box. But maybe endless puzzles for ever cleverer people is the point of it all.
qingcharles 2 days ago [-]
I dunno. I was a gamedev. I'm pretty sure everything got thrown out. I don't remember ever taking any source home. It was all managed through Visual Source Safe (!) on a local server.
The 80s games were mostly coded in bedrooms, but after that it all moved to teams in offices and a lot of studios went boom-to-bust pretty quickly.
Asooka 1 days ago [-]
That's better than the games not being made in the first place because the Ministry of Culture deems it unimportant and puerile, which is what happens in Communism. You also can't have indies, because you can't publish anything without the state's approval, not to mention you also can't sell things for monetary gain.
I think 80-ish days to recompile and old binary is a much better alternative to the total death of human arts and innovation, and the unending list of crimes against humanity that Marx's theory has led to every time it has been applied.
But to keep it a bit more videogame related, Marx always reminds me of this speech by senator Armstrong of Metal Gear Rising: https://www.youtube.com/watch?v=IMpuUUV2HeE . "We will use an absolute totalitarian state to abolish the state" - a lofty goal turned into complete lunacy.
rowanG077 2 days ago [-]
Its really great how we can breathe new life into older games like this. I'm currently working solo on a Tales of Symphonia gamecube decomp. My aim is to let AI do everything of substance. currently about 3400 functions are exact out of about 4800. So still a way to go. But I haven't written a single line yet.
StilesCrisis 2 days ago [-]
How did you get started? I have a project in mind and would love to try, but getting a foothold on it feels really hard when you are starting with an ISO image and an empty folder.
But in essence it's not so complex. You only need the original compiler that was used to compile the game and tools like ghidra. Binutils for the architecture can help. From there you ask the agent to start building the project. Prepare to spend a ton of tokens though if you go the full AI route.
StilesCrisis 15 hours ago [-]
TBH I'm not even that interested in getting byte-for-byte reconstruction. I just want to bring an old game back from the dead.
rowanG077 12 hours ago [-]
Yeah I get that. The problem is that with AI decomps you really need a clear and verifiable target and exactness solves that problem. If you step away from that you basically leave any agent free space to cheat.
StilesCrisis 10 hours ago [-]
Yeah, that makes sense. Even taking AI out of the equation, that's how you know a decomp is actually right--it matches.
rjrjrjrj 2 days ago [-]
I don’t remember this game at all - and there weren’t many N64 games, especially in the first couple of years.
It and the sequel were among two of the best multiplayer games on the system. It was so sad to see the series die when it went portable instead of continuing to be a ton of fun.
rjrjrjrj 2 days ago [-]
Interesting.
For me it was Goldeneye (of course) and Diddy Kong Racing.
ThrowawayTestr 2 days ago [-]
Awesome. Hopefully AI will allow more games to be decompiled in the future. Anyone working on a decomp of Perfect Dark?
QuantumNomad_ 2 days ago [-]
https://github.com/n64decomp/perfect_dark claims to be “a complete decompilation of Perfect Dark for the Nintendo 64”. And: “When a matching decompilation is compiled with the same compiler that the original developers used, the output will be exactly the same as the retail game, byte for byte.”
Relatedly, https://github.com/perfect-dark-pc-port/perfect_dark forked from the above describes itself as “a work-in-progress port of the Perfect Dark decompilation to modern platforms”. Further: “The game is in a mostly functional state, with both singleplayer and split-screen multiplayer modes fully working.
There are minor graphics- and gameplay-related issues, and possibly occasional crashes.”
40four 22 hours ago [-]
I grew up in prime N64 era, and played countless hours on the console. But I definitely never played, let alone even heard of the Snowboard Kids title. How did I miss this game? Am I the only one?
beepbooptheory 2 days ago [-]
Does decompiling a game made by a certain development team help decompile others made by the same people? Because you might know what patterns to look for?
qingcharles 2 days ago [-]
No, not at all. I know where I worked there was zero code reuse across teams and games.
Games of this generation had code that wasn't intended to be supported or managed after release (no patches for those consoles) and so the code tended to be fairly horrible.
Sesse__ 1 days ago [-]
Yes. Especially when there are common libraries and you can reuse their names, structures or even entire decompiled routines.
There's a fair amount of folklore going around, but less direct sharing than would be ideal.
hn773746483 1 days ago [-]
It varies. Nintendo for example has plenty of different teams and internal frameworks, but not every game uses them.
jdw64 2 days ago [-]
I love the game Monster Hunter2 so much that I once practiced decompiling it. I worked on it for about two months and got maybe 5% done. Sometimes I really admire people who do this kind of decompilation work.
minimaxir 2 days ago [-]
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 project irrevocably.
fizwidget 2 days ago [-]
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.
ndiddy 1 days ago [-]
Yeah the problem isn't people using AI, it's the flood of lazy "native ports" that have no meaningful improvement over playing the game in an emulator and often crash or glitch out a level or two in because unsurprisingly a lot of the people who leave all the work to Claude don't feel like testing the game themselves. LLMs are a godsend for RE work when they're used properly, but a lot of these projects just waste everybody's time.
trelbutate 2 days ago [-]
to be fair much of the fun in decompiling/RE is the puzzle solving, it's like a giant crossword puzzle that you fill in bit by bit, slowly figuring out how things work.
Having an LLM do large parts of that for you is probably kinda boring for many.
spijdar 2 days ago [-]
The problem isn't that people consider it boring, it's that the use of LLMs is considered essentially sacrilegious, and whatever end-result that's created is considered tainted, often regardless of the extent of LLM usage.
Which does kind of suck. Yeah, it's not nearly as cool to say "I prompted a probabilistic pile of tensors and it did the hard work for me", and I think it majorly adjusts how "impressive" projects are. There's no point pretending like decompiling a game by hand and using GPT-6.7 to do it are remotely comparable.
The suck-y part is that if you do the decomp with GPT-6.7 and produce, say, a PC port of an early 2000s console game, a large number of people will refuse to touch it and treat it as if you have committed a cardinal sin. Maybe that's justified? I dunno. It definitely goes beyond people just saying it isn't as fun.
Sesse__ 1 days ago [-]
> Yeah, it's not nearly as cool to say "I prompted a probabilistic pile of tensors and it did the hard work for me", and I think it majorly adjusts how "impressive" projects are.
Vibe-decomped projects are also… a different result.
A matching hand-decompile is useful in itself, but it also serves as a proxy for how well you understand the project; how good are the function and variable names, are the structures good, do you understand the entire flow. There are plenty of LLM-decompiles out there that just match but still every variable name is “unk14”, where every flow is total spaghetti instead of going back to something closer to what a human would have written, or even tons of __asm__ statements. The match stopped being a high-quality proxy metric for the quality of the project as a whole. (There are also LLM-assisted decompiles that are high-quality, but then usually with significant human input. And of course, you can try to ask the agent to clean up the resulting mess after you're done matching, assuming you have any tokens left.)
Of course, if you just want the binary back and collect Internet points, you don't care about any of this. But decompilation projects are often made for either a) understanding the game better (for speedruns, TASes, or just general explanation), or b) modifying it. And for both, it is much nicer to have source that is closer to the original.
miladyincontrol 2 days ago [-]
Its curious the cultural differences you see in some places too, a not too uncommon Japanese one I've seen is where the cardinal sin is "stealing" other people's creative works, rather than anything specifically involving LLMs.
Meanwhile so many westerners see LLMs as "stealing IP", it becomes a bit paradoxical where the lines get drawn.
SpecialistK 2 days ago [-]
Even Japanese attitudes towards IP are not that clear cut. One of the reasons the MiniDisc format was so popular in Japan vs the rest of the world was that physical media in Japan is expensive, so there are stores which rent out CDs. Those CDs would often be copied to MD (or later to PCs.)
userbinator 1 days ago [-]
The backlash will soon die out once the majority see the results.
(Of course there will always be the annoying "never AI" virtue-signalers, but the same can be said about anything.)
fzeroracer 2 days ago [-]
The backlash has only been growing as the result of a significant number of incredibly sloppy decomps, either creating unreadable codebases or outright being so buggy/inaccurate as to be useless. Every day I see another decomp pop up that exists solely for the cred of being the first to do so, which is then promptly abandoned by the developer because it doesn't fucking work.
doctorpangloss 2 days ago [-]
on the flip side retro games are almost completely and entirely an aesthetic experience. like if something totally subjective and personal like nostalgia is not just a valid reason, but the #1 reason, to be engaged with retro gaming, why isn't some random condition about the process of resurrecting the games also valid?
i think you agree that there is. but it should change your language about this idea of "consumers" and "benefits" - like this is the difference between making code and making a product. nobody NEEDS retro games. in my opinion, they aren't even that good! they are completely and utterly an aesthetic experience. the process IS the product.
Levitz 2 days ago [-]
If the process is the product, then anyone who is not involved with the process has no right to say anything about the product.
Not to mention, there's a lot of stuff beyond an "aesthetic experience". Videogames have historical value, and they have relevancy at the very least as a testament of the state of the industry at any given point.
Legend of Dragoon, for example, integrated QTE-like controls in its attacks, even as a turn-based game. FFVIII, released the same year, implemented interaction in a somewhat similar way. These two are very early predecessors to mechanics Clair Obscur: Expedition 33 much more recently used. That has value.
If anyone wants to establish random conditions as to why they consider a work to be worthy or not, they may have those. But then they should keep them to themselves, rather than pretending people shouldn't care about something because of the way it was done. It's like the classic situation of someone complaining about how some open source project doesn't do something exactly in the way they like. I have nothing but contempt and despise for that sort of people, and it's a whole order of magnitude worse here, where the "problem" stems from their political stance, which nobody with a pulse should give a crap about.
doctorpangloss 2 days ago [-]
[left hand emoji] you have very strong feelings about something, you're sharing it with others on a public forum
[right hand emoji] "their political stance"... "they should keep them to themselves"
ur-whale 1 days ago [-]
Fantastic work, but my gut reaction: Why?
Why snowboard kids and not the ocarina of time ????
Because it's there. Less famous games can have nostalgic value for people, and many are good. I really like Snowboard Kids myself so I got a kick out of it.
But also, Ocarina of Time has pretty famously been done and subsequently ported everywhere a couple of years ago.
sota_pop 1 days ago [-]
- super smash bros
- LoZelda Ocarina of time& majora’s mask
- starfox 64
- Mario party
- extreme G racing
- jet force Gemini
- golden eye
- conkers bad fur day
- Mario 64
- Tony hawk
Man… so much nostalgia
2 days ago [-]
throwaway613746 2 days ago [-]
[dead]
NooneAtAll3 2 days ago [-]
I'm still baffled by RE community aiming for "100% asm match", needing to reproduce specific compiler version, instead of aiming for functional equivalence and cleaner code
is there really no tools whatsoever that produce proof certificates for "these two functions do the same thing"?
Jegber 2 days ago [-]
Game behavior can be tied so closely to quirky hardware behavior that I doubt such a tool would be simple to create. You’d have to verify that your code produces the same hardware state. And different (ie more efficient) code almost by definition produces a different hardware state than the original code. Thus changing the game.
qarl2 2 days ago [-]
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.
DSMan195276 1 days ago [-]
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're used, etc.).
unknownfuture 1 days ago [-]
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.
qarl2 1 days ago [-]
Sure.
I guess I'm assuming that sloppy and buggy software didn't much become popular.
Because it was sloppy and buggy.
DSMan195276 20 hours ago [-]
Why would you assume that? That's not even true of regular software :D
But also, as long as the game works on the specific hardware it was designed for then that's all that mattered, which was my point. If it reads uninitialized memory or depends on exact cycle counts or some undocumented hardware behavior then that's _fine_ if it still works on the real hardware, plenty of that was even intentionally done to achieve things otherwise impossible on that hardware.
At the same time it makes it almost impossible to verify even trivial changes to a function. Once you start accounting for all the potential state differences the answer to "does this function work the same?" will basically always be 'no' unless the code is identical. The only way to eliminate various kinds of state from being a concern is to analyze where the function is _used_, rather than just the function itself, and that's an entirely different and much harder kind of challenge.
qarl2 20 hours ago [-]
> Why would you assume that?
Why would I assume that sloppy and buggy software would be less popular?
I'll have to get back to you on that one.
unknownfuture 2 days ago [-]
Because byte-for-byte identical output is far easier to measure than trying to test for functional equivalence.
This is also partly a preservation activity so (as best we can create it) identical code generating identical output is a big part of the point.
qingcharles 2 days ago [-]
It's usually just the first sweep to make sure everything is understood and documented before you start to make mods.
xyzsparetimexyz 1 days ago [-]
No. Halting problem.
VCFundedGenYer 2 days ago [-]
Unfortunately, the community will not accept an AI-assisted decomp. Gotta do it for real.
I'd also encourage people to check out the Legend of Dragoon recomp [1]. It's a real labor of love that has breathed new life into a largely abandoned game. You can play it fully vanilla, or with improved graphics, fixes to cumbersome design choices, bugfixes, etc.
[1] https://legendofdragoon.org/projects/severed-chains/
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 music straight out of the ROM. Mapped out all of the music that way. It was incredible.
Have neen reverse engineering my laptop's BIOS as well. AI is fully in charge of that one, and it's nearly done. Hopefully soon I'll have drivers and perhaps even coreboot.
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.
I remember one game had a crude speech synthesis and I discarded the game and persisted out the speech synthesis code independently as a separate program to play with arbitrary input.
I had hoped to someday make retro games for all major 80s and 90s consoles. I started with the Atari 2600 12 years ago[0], and planned to move to other 6502 family systems when I had time. I realized last year that AI could essentially do all of what I considered the hard parts and craft of retro game assembly, which felt like having the rug pulled out from me. Projects like this have really turned that around for me.
New tools just mean old things become easier and new things become the difficult (where I think the fun is), but solvable, frontier. This category of projects inspired me to pick back up an Ultima V decompilation project I started more than 10 years ago[1,2]. I'm looking forward to a world where all of my childhood games are cracked wide open for mods, ports, etc.
[0]: https://github.com/cleak/FlappyBoot [1]: https://github.com/cleak/u5-spec (spec for Ultima V binary) [2]: https://github.com/cleak/u5-engine (Rust port of Ultima V made from the spec; still lots of prose slop)
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 them simply not wanting to.
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.
You become a machine with your workflow, once again limited only by your time/energy, tokens, and your discretion on how to spend it.
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...
Disassembler output can relatively easily match original binary, I doubt anyone would consider it decompilation.
Let's say you add requirement of being higher abstraction language than assembly. You can translate the assembly code 1:1 with simple string substitions to C code which would provably replicate the behavior of program perfectly. I would consider that more of hard coded emulation, opposite of JIT like ahead of time code translation. Just because the intermediate langauge is higher level language than assembly doesn't automatically mean that the program text operates at higher level of abstraction than assembly.
I have seen plenty of decompilation projects where you start reading the code many functions contain nonsensical variable reuse (and name that match the register names), address calculations and memory casts and array calculations, arrays of function pointers, offsets within structures which strongly mirrors the assembly code.
The problem is that you can't draw a hard line how good do the variable/function names need to be so that it can be considered decompilation instead of hard coded emulation. It's hard to draw a line for how much of higher level language features you need to use to be considered decompilation. It's hard to define how logical the control flow needs to be. The line becomes blurrier by system programmers approaching it from the other side. Sometimes an extensively optimized code can contain a lot more manual memory mangling, index and offset calculations, manual unrolling than the language requires. So many C programs with homebrew systems of emulating virtual functions using structs of pointers. In such situations it's hard to tell if decompilation is incomplete or whether program was written that way from start.
Another possibility of junk decompilation (which perfectly compiles to byte identical copy of original executable) is program which depends on exact program layout in memory or undefined aspects of programming language. It would perfectly replicate original behavior on original hardware/compiler, but provide 0 insights in intended program behavior and fail miserably when attempting to modify the code or port it to different hardware/compiler. For example the "decompiled" code might intentionally peform out of bounds array access thus touching completely different variable or depend on fallthrough between functions lacking return statement.
Taking it to the extreme would be something like:
```
char data[] = {0x10, 0x12, 0xab, 0xcf, ...}; // bytes corresponding to majority of original program.
int main(){ ((void*())data)(); // cast the array to function pointer and execute it
} ```
It might behave exactly like original program, but that's junk decompilation.
You could add additional restriction that C program isn't allowed to exploit any undefined or machine specific behavior, but then there is very high chance that even original program wouldn't satisfy it.
Original program might also contain parts of it written in assembly for performance reasons or because that was only way to access certain hardware features. What does it mean for decompilation? Is decompiled code not allowed to use the same techniques. If decompiled code is allowed to have some pieces of assembly what stops it from using it for everything. There is no way of knowing precisely how much assembly the original program used.
Indeed. But I think it's fair to say that just embracing LLMs is not enough.
Not your handwriting, not your work!
Not to mention, LLMs can be made deterministic if that were actually valuable.
Seems like determinism is just the latest excuse to hate.
There’s a reason why the top comments of HN blog posts whine about articles that are clearly written by AI. I use AI constantly as a coding agent, but I care deeply about the authenticity of the words I write intended for other human beings to be my own.
I hope you understand, by so glibly switching from "determinism" to "authenticity" you've just provided more evidence that this is just the latest excuse to hate.
But that aside - what happens in a couple years, when LLMs inevitably improve, and their writing is objectively superior to human writing? And people who just want to read well-written material won't care about the authenticity?
I suspect there will be another glib switch. Because the reality here is just that AI is hated. Full stop.
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 functional in a few years.
I suspect that a lot of people who are going full hog on LLMs aren't actually making up the difference, and are simply offloading their thinking. I choose to not be one of those. I'll use them at work because they make me faster and most of the code is already not mine. It's a means to an end. My personal projects are for the fun and love of programming, not just to have some software in the end.
I for example, let the AI generate inbetween reports for a hobby project. These reports describe me how the project looks, stages, progress, etc.
I do know plenty about this particular project.
Also i wrote tons and tons of CRUD apps, do I really loose anything if that one quiz i did for learning, i don't understand in detail?
A more appropriate analogy for what you just described might be writing vs ghost writing.
But it's certainly not handwriting vs typewriter.
Note: there's no implied value judgement here.
My point is that the analogy that LLMs are equivalent to typewriters is fundamentally broken. Using an LLM to create text, and writing using writing tools, are simply completely different activities that just happen to lead to (at least superficially) the same outcomes.
Similarly, downloading a vase and 3D printing it isn't the same as making pottery. Programming a knitting machine to make socks for you isn't knitting. Putting text on paper using a printer isn't calligraphy.
And I'd argue we're going to collectively conclude that assembling software systems using AI isn't coding.
Again: no value judgement. But life isn't always just about outcomes. Process does, in fact, matter, and I think it's important we maintain these distinctions.
It's genuinely amazing and baffling to me that a non-trivial number of people around here don't seem to grok that.
Think about the act of writing with a pen.
Now think about what a typewriter does in that context.
Now think about what an LLM does in that context.
Can you reason about how those are vastly different tools within the context of writing or communication, so much so that the comparison doesn't actually make any sense?
Hint: it has nothing to do with determinism. It has to do with the nature of the work itself and the role of the person doing it.
As an aside, this whole exchange really is just a perfect encapsulation of the outcome-focused versus process-focused individual.
The outcome-focused person sees words in a document and whether an LLM produced them or a human typed them is a distinction without a difference.
The process-focused person is utterly baffled that anyone could think those are in any way equivalent.
HEH. I just read your comment three times and I definitely don't get it. I think its entire point is to express outrage about not getting it, rather than actually explain it.
Bafflement? Certainly.
Maybe a little sadness at the lack of understanding of, or appreciation for, the creative process? Sure.
Outrage? Nah.
I only see that construction used condescendingly.
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 lower than Trig (I never got to Calc in high school).
Funny, but your statement reminded me of what one of math teachers used to say: "If you use a graphing calculator, you aren't doing math." It seems really quaint today.
Same with AI. Having AI generate a for loop doesn't mean you understand the concept of a for loop. You can argue that it's a waste of time to learn about for loops because an AI can write one for you but that's a separate matter.
Another example is computer algebra systems like Mathematica. It would be self-sabotage to use them on your calculus homework, but they're indispensable to the working mathematician, physicist, or engineer, whose time is wasted doing routine calculations by hand.
I then spent way more time than what I would have spent without the plotter to figure out that a pole and a zero were located right next to eachother.
I had no idea if the teacher had done that on purpose, but it made enough of an impression on me that I still remember it.
The point of math exercises is usually not to get to solution as quickly as possible.
Throw in "and when the batteries in your calculator die, you'll need to know how to do it by hand!" for good measure. :-)
I jest...
If the math teacher is unaware of the difference between "math" and "arithmetic", what are you even talking about?
Then he brought the graphing calculators in and had us plot graphs on those, compare them to our hand sketches, and set domain and range on the graph based on the critical points we found. He emphasized that doing the math beforehand let us use the graphing calculator effectively, and without knowing the math the calculator was useless.
Which sounds like the most sensible voices w.r.t. AI. At least for now. Six months ago I would not trust AI for any but rather menial tasks, but frontier models are able to do more and more of what I do every time I turn around. The TI-83 has been a fixed quantity in terms of capability since the 90s, and it never computed derivatives itself.
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?
Downloading a bunch of open source libraries and putting together some project with a bunch of glue code also requires little thinking, but before AI no one really said that was "cognitive surrender". People even got pats on the back... for using other people's work to build something.
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.
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 entire profession by Hackernews posters; most of us are in the upper quartile or so.
These days, for small to medium-sized tasks, frontier LLMs are consistently well within that upper quartile. People at my level have a lot to be concerned about, as most of our day-to-day can be automated away. Sure, there's need for judgement and architectural discipline, but in most shops that's done by the people we used to make fun of in the 2000s, who sit in design review meetings and produce box-and-arrow diagrams, not code. Those are now the real bringers of value to a software development company or division.
At a bare minimum, it is irresponsible to ship code that has any sort of security requirement without using AI. Frontier models are able to discover zero days in minutes that would have taken months with human investigators, and if you're not auditing and red-teaming your own code with AI, someone else will use AI to pop it.
You are just not working to a professional standard in 2026 if you're not using AI.
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?
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.
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?
So what that means is that you the software engineer need to be doing what you should have been doing all along: start with systems analysis, stepwise refine that into a program specification, then break that into tasks to give to your programmers to implement. Per PRIDE, the sadly forgotten but comprehensive common-sense information systems methodology, the analysis and specification phases should take up the bulk of the time on a project, with actual programming taking up 15% or less. LLMs can drive that time asymptotically towards zero for human developers. The specification is the deliverable. As a former boss of mine put it, you should be able to delete the entire source code repository and get functionally the exact same software back by running the spec through the LLM.
But you're working with a stochastic system. Even GPU matrix calculations are nondeterministic. It isn't possible, to the delete the entire source code and get exactly the same software back.
And any spec, that is specific and non-ambiguous enough to carefully construct the exact needs of each is... Well, that's code. Not a PBI, not an Epic. It's code.
If you produce a spec that is entirely unambiguous in every way, again, that's code. That's the purpose of a programming language - distilling from the natural ambiguities of natural language, to specificity.
LOL
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?
Yes.
Even if you're the owner of the game, the contracts for the voice actors, motion capture, models, etc. frequently define very narrow terms of usage. Defining the exact release platforms is common. Not to mention profit sharing if the actors or studios you're hiring are popular.
It's even worse for retro games. Many times the original rights holder went out of business, sold their rights, died, or something else that muddies the ownership chain.
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 film or games, the effect on artists or designers can be pretty depressing.
So yes, games are not unique in this way. I am hopeful in the optimistic future case where LLMs lead to lower barriers to entry, UBI, and so forth that copyright essentially disappears, or at the very least is severely reformed.
Many things should simply enter the public domain at a far more accelerated rate.
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.
Isn't the current system setup around the idea that the company gets the rights, and in return the workers get a basically risk-free salary? Wouldn’t your proposal undo that, so then workers took on the risk of whether they got paid, based on whether the game ends up being profitable?
Since I'm just pitching wild ideas on the Internet of course I have the freedom to make any suggestion I want, but I would like to live in a world where (a) no companies or rights owners are able to play bullshit games with gating access to art that can be reproduced at trivial cost and (b) we can consume all the art we want that's past its sell-by date. It's insane to me that we don't have free, legal databases of every work of art created before, say, 2006.
Then again Disney's old "vault" strategy would counter it, and Nintendo is already toying with it to sell through FOMO. How can it be this hard to make companies keep our digital culture available for sale? It's not even charity.
I don't disagree with the spirit of your argument. I'm just saying that my proposal would be a lot easier to put in practice than anything that hurts companies. The strength of the proposal is exactly that companies will mostly shrug while creating a very clear legal separation of what's "active copyright" and what's an "abandoned work".
By the way, this would also apply to the GPL (and other copyleft licenses).
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 <Game> 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.
Worth a look if you want a bit of nostalgia.
https://github.com/perfect-dark-pc-port/perfect_dark
Ported it to OpenBSD for fun an evening about a year ago.
Here: https://github.com/Alex-LeTux/perfect_dark_VR
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.
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.
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 labels or symbols. Not what most people would consider “the original assembly”.
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.
(I like these projects but I really don't think they could defend themselves legally if you company went after them)
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, intended for owners of the game to play the original game on a different platform or in a modified format, and not likely to have a negative effect on the original work's desirability or value. And, the reproductions aren't complete and alone usually produce limited to no value to a consumer (usually, they won't start without the original game files). These are the other important factors considered in fair use determinations and generally go the way of these being OK.
So, it's hard to say. With reverse engineering and copyright in the US in general, context is crucially important; something that would be completely illegal for one purpose (ie - decompiling and recompiling a competitor's software to distribute it without a license or use it internally without purchasing it would be obviously illegal) could be OK for another one.
Then a freshly written project would be completely different with no derivative elements at all; the only commonality between the two codebases is their functional elements. You can compile a decomp into the same binary, but that's only to prove functional equivalence. The intended mode would be with a modern compiler that completely rewrites the logic (it might even have to if it writes it for a completely different computer architecture, which describes every retro console game). Then neither the source nor the compiled artifact would match.
I strongly disagree with this notion from even a conceptual (much less legal) level; the point of compilation is not to erase the algorithms the programmer implemented, just to optimize and implement them.
> You can compile a decomp into the same binary, but that's only to prove functional equivalence.
This is like saying that a translated book is only "functionally" identical to the original; there's a lot of precedent in copyright law for this not being the case, and I don't think any argument revolving around the transformativeness of the compilation process would fly at all.
Programs as written are nothing like programs as compiled, certainly not as an expressive endeavor. Books don't have an analog. There's no point where we strip all conceptual meaning from the book and leave only the procedural algorithms the semantics demand. There's no point where we replace all the individual words with autovectorized versions, or where we automatically delete impossible sentences, or remove every layer of abstraction that the programmer put in there exactly for the ability to convey ideas.
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.
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.
A reimplementation or a behavior-based clone is an entirely different legal world from decompilation.
In fact, the goal of most decomp not to produce the same binary, that’s just used as a validation.
True, but as a derivative work of the original source code they don't have rights to do anything with that code without infringing copyright.
Also, If it is an unauthorized derivative work, as I understand it then it might not even qualify for copyright protection itself.
I’m really curious about trying this myself. Recently I’ve been handing off tasks for agents to complete on their own more and more. While their work is acceptable I’ve found them to not only take a long time to complete it, but they often add too much complexity and tests.
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.
there was official source code release for 6502 port, why not match names from that one?
What took me the most time was actually the beginning: building a mental model of what assembly patterns map into which Pascal patterns, and finding good areas to start writing code from. In hindsight, I should have probably started by generating inline assembly equivalents of each procedure/function. The ending was relatively smooth sailing in comparison, but it is of course much easier if the compiler you're targeting doesn't do much in the way of optimization passes, so it's not representative of decompilation work for more modern targets.
The 80s games were mostly coded in bedrooms, but after that it all moved to teams in offices and a lot of studios went boom-to-bust pretty quickly.
I think 80-ish days to recompile and old binary is a much better alternative to the total death of human arts and innovation, and the unending list of crimes against humanity that Marx's theory has led to every time it has been applied.
But to keep it a bit more videogame related, Marx always reminds me of this speech by senator Armstrong of Metal Gear Rising: https://www.youtube.com/watch?v=IMpuUUV2HeE . "We will use an absolute totalitarian state to abolish the state" - a lofty goal turned into complete lunacy.
But in essence it's not so complex. You only need the original compiler that was used to compile the game and tools like ghidra. Binutils for the architecture can help. From there you ask the agent to start building the project. Prepare to spend a ton of tokens though if you go the full AI route.
For me it was Goldeneye (of course) and Diddy Kong Racing.
Relatedly, https://github.com/perfect-dark-pc-port/perfect_dark forked from the above describes itself as “a work-in-progress port of the Perfect Dark decompilation to modern platforms”. Further: “The game is in a mostly functional state, with both singleplayer and split-screen multiplayer modes fully working. There are minor graphics- and gameplay-related issues, and possibly occasional crashes.”
Games of this generation had code that wasn't intended to be supported or managed after release (no patches for those consoles) and so the code tended to be fairly horrible.
There's a fair amount of folklore going around, but less direct sharing than would be ideal.
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.
Which does kind of suck. Yeah, it's not nearly as cool to say "I prompted a probabilistic pile of tensors and it did the hard work for me", and I think it majorly adjusts how "impressive" projects are. There's no point pretending like decompiling a game by hand and using GPT-6.7 to do it are remotely comparable.
The suck-y part is that if you do the decomp with GPT-6.7 and produce, say, a PC port of an early 2000s console game, a large number of people will refuse to touch it and treat it as if you have committed a cardinal sin. Maybe that's justified? I dunno. It definitely goes beyond people just saying it isn't as fun.
Vibe-decomped projects are also… a different result.
A matching hand-decompile is useful in itself, but it also serves as a proxy for how well you understand the project; how good are the function and variable names, are the structures good, do you understand the entire flow. There are plenty of LLM-decompiles out there that just match but still every variable name is “unk14”, where every flow is total spaghetti instead of going back to something closer to what a human would have written, or even tons of __asm__ statements. The match stopped being a high-quality proxy metric for the quality of the project as a whole. (There are also LLM-assisted decompiles that are high-quality, but then usually with significant human input. And of course, you can try to ask the agent to clean up the resulting mess after you're done matching, assuming you have any tokens left.)
Of course, if you just want the binary back and collect Internet points, you don't care about any of this. But decompilation projects are often made for either a) understanding the game better (for speedruns, TASes, or just general explanation), or b) modifying it. And for both, it is much nicer to have source that is closer to the original.
Meanwhile so many westerners see LLMs as "stealing IP", it becomes a bit paradoxical where the lines get drawn.
(Of course there will always be the annoying "never AI" virtue-signalers, but the same can be said about anything.)
i think you agree that there is. but it should change your language about this idea of "consumers" and "benefits" - like this is the difference between making code and making a product. nobody NEEDS retro games. in my opinion, they aren't even that good! they are completely and utterly an aesthetic experience. the process IS the product.
Not to mention, there's a lot of stuff beyond an "aesthetic experience". Videogames have historical value, and they have relevancy at the very least as a testament of the state of the industry at any given point.
Legend of Dragoon, for example, integrated QTE-like controls in its attacks, even as a turn-based game. FFVIII, released the same year, implemented interaction in a somewhat similar way. These two are very early predecessors to mechanics Clair Obscur: Expedition 33 much more recently used. That has value.
If anyone wants to establish random conditions as to why they consider a work to be worthy or not, they may have those. But then they should keep them to themselves, rather than pretending people shouldn't care about something because of the way it was done. It's like the classic situation of someone complaining about how some open source project doesn't do something exactly in the way they like. I have nothing but contempt and despise for that sort of people, and it's a whole order of magnitude worse here, where the "problem" stems from their political stance, which nobody with a pulse should give a crap about.
[right hand emoji] "their political stance"... "they should keep them to themselves"
Why snowboard kids and not the ocarina of time ????
- LoZelda Ocarina of time& majora’s mask
- starfox 64
- Mario party
- extreme G racing
- jet force Gemini
- golden eye
- conkers bad fur day
- Mario 64
- Tony hawk
Man… so much nostalgia
is there really no tools whatsoever that produce proof certificates for "these two functions do the same thing"?
Seems more like voodoo.
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're used, etc.).
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.
I guess I'm assuming that sloppy and buggy software didn't much become popular.
Because it was sloppy and buggy.
But also, as long as the game works on the specific hardware it was designed for then that's all that mattered, which was my point. If it reads uninitialized memory or depends on exact cycle counts or some undocumented hardware behavior then that's _fine_ if it still works on the real hardware, plenty of that was even intentionally done to achieve things otherwise impossible on that hardware.
At the same time it makes it almost impossible to verify even trivial changes to a function. Once you start accounting for all the potential state differences the answer to "does this function work the same?" will basically always be 'no' unless the code is identical. The only way to eliminate various kinds of state from being a concern is to analyze where the function is _used_, rather than just the function itself, and that's an entirely different and much harder kind of challenge.
Why would I assume that sloppy and buggy software would be less popular?
I'll have to get back to you on that one.
This is also partly a preservation activity so (as best we can create it) identical code generating identical output is a big part of the point.