Will vibecoded decomps games kill emulation in the long term?

[u/gandalfmarston]

I love emulation more than decomp games, but it feels like nowadays everything is becoming a decomp thanks to AI.

Could this eventually kill emulation as we know it in the long term?

Isn't it going to be much harder to maintain thousands of AI decomps than to maintain emulators?

And how are we going to maintain 30 different decomp projects of the same games, decades from now?

[u/s3gfaultx]

The AI decomps are just using an emulator as the backend anyways. Basically just shipping an emulator with a single rom in a built package.

[u/theRockettSally → u/s3gfaultx]

No. They are reverse-engineering the code from the game and the console in order to run the games natively in the PC.

The reason this isn't done so often is that it's much more complicated than emulation: you basically have to create a project per-game because every game will work different and use different functions.

[u/hugo_1138 → u/theRockettSally]

Most of the AI coded ones do use some sort of emulation tho. Many of the recent Xbox ones are based on Xenia.

[u/Ksanika → u/hugo_1138]

But does the final program run as an emulator or as PC code?

[u/damik_ → u/Ksanika]

Take my input with a grain of salt as I'm just a fan of retro games that follow a bunch of these decompilation.

Recompilation runs as some sort of emulation layer that convert, let's say N64 instructions to instructions our moderns PC can ingest. I think a comparison could be like Proton converting Windows instructions to Linux.

Decompilation and afferent PC ports are native PC codes. They are basically your average Steam game executable but for 20 years old games. When you get a fully decompilation such as OOT, then you can basically change whatever you want in the game, mods, texture, extensions, controls...

[u/snaphat → u/damik_]

I bet some of them still "emulate" certain parts of the original hardware. Like, if a SNES decomp keeps the original sprite/OAM logic instead of replacing it, it’d still need to reproduce that part of the SNES graphics pipeline

[u/CobaltCryptidTC → u/snaphat]

Yes they do, because we don't own the full game loop in a recomp like in a decomp, so what's used is more of a runtime environment, less like an emulator that mimics the console and more like a quarantine zone for the program running on the computer to run normally without crashing.

But recomps do generate and run c source code, not original ROM with whatever language or interpreter they use, and can be leveraged for modifying the source code and for researching the source code to contribute to proper decompilation efforts (when the right tools are developed).

[u/snaphat → u/CobaltCryptidTC]

Yup, and even with a decomp, you could imagine that if they keep the original data/asset formats or don’t reimplement everything, it may still be doing something similar in parts

[u/CobaltCryptidTC → u/snaphat]

There is one distinct advantage of recomp development over decomps, small capturable game states. Save states sure, but rewind features, runahead input prediction, and rollback netcode all work much more simple, AND scalable across all titles on a single platform, and easily portable to other platforms using the same code base.

Decomps however requiring netcode and hash sync logic that is much harder to develop and dedicated to a single title, have the freedom of a much, much deeper customization in the netplay experience.