I think you/that article are overthinking it. Compiling just means turning source code (written/readable by humans) into machine code (aka a program/game). “Decompiling” is the reverse of that, where you turn machine code into source code.

A lot of these AI de/re/comp/port/whatever projects are made by script kiddies/morons who don’t know what they’re doing. Sometimes you see them claim that a project is a “static recompilation”, but when you look at the code it’s literally just a bespoke emulator that runs the game.

Which is to say, don’t get too hung up on these terms, since they’re often misused either way.

It’s important to understand that these terms are not standardized and people or organizations may use them slightly differently or interchangeably. This can cause confusion. But in the wild, people have come to use these terms (in my experience, I’m not an expert either) in specific ways. The article you linked seems to do a pretty good job, but we should remember that this is his/her personal interpretation. From your explanation, I would say it sounds about right “in my opinion”.

I lost it and put this lengthy reply. Sorry about that. Edit: Some parts are still not good explained, I tried.

Source code and compiled binary

First, it is important to understand the two states of a game: source code and compiled binary. The source code is text form written in a programming language (usually by and for humans), with other source material. If you download source code, its just bunch of text files basically. To play the game, one need to use a compiler that compiles or transforms the text files into machine readable compiled binary files. There are other stuff too, but this is the important part. The game can now be run and played on the platform it was built for, such as Super Nintendo. If you create a backup of the Super Nintendo cartridge that holds the compiled binary, then you get a ROM file basically. And on your PC you can’t run the Super Nintendo games without emulating the hardware.

Assembly

Every CPU has a set of codes and functions, the very basic at the lowest level possible. Assembly is basically that, it is basically the native language the CPU understands. If you code in Assembly, then it is for this specific CPU architectur, such as Super Nintendo. But the CPU only can understand zeros and ones. So you have to translate the Assembly into real machine code, but the logic does not change anymore. So Assembly is machine code, just wrapped up in a better human readable form. This is usually not the source code. Source code is compiled into Assembly and then machine code binary. You can think of Assembly as machine code for humans, if that makes sense.

Reverse Step 1: Disassembly

Disassembly is taking the compiled final binary (such as ROM files in example) and does just translate all the zeros and ones into human readable machine code. But the original variables names and such are lost, so that its hard to understand what this even is due to optimizations by the compiler. Humans have to go through each line and machine code (which is represented in Assembly format) and figure out what each of the lines, commands do, rename each function and so on. This is painful work. What you get is Assembly code that is readable by humans.

When you compile a fully reverse engineered Assembly code, you get the exact same ROM or machine code that you just disassembled. It didn’t change the code, it just renamed stuff basically. So it will just compile to what it was programmed to.

Reverse Step 2: Decompilation

Now that you have something humans can read and reason about their logic, it’s time to write some real and original source code. That means trying to understand the parts in Assembly, then writing in (in example C or Rust language) a language that can be compiled to any other target than the original machine code was intended. This new code is an approximation of what the original source code of the game developers were, but we don’t know.

Now this process is painful and slow. And in the end it does not mean the code will compile to other platforms, it still aims to produce the original game logic for the original hardware (such as Super Nintendo). So they need to make adjustments to the source code, which is finally easy to work with.

Reverse Step 3: Port

Now that you have an easy readable source code in a programming language that is independent from the hardware, such as C or Rust, you can make adjustments. If you aim to play the game on PC, then adjustments are done so it can compile on PC. Whatever is needed, but in short they modify the source code to be able to compile it to other platforms than it was originally intended. That’s a port.

What is a recompilation?

In context of this discussion, a Recomp is basically taking the binary of the game and automatically built a source code file (such as to C or Rust) in one step. This leaves out the manual work of humans to categorize, understand and write good human readable code. The produced code from recompilation is meant to be used by compilers only, that compile to binary. It is not intended to be read by humans, even though its technically source code. Disadvantage is, that if there are bugs then humans have a hard time figure out whats going on. Or to mod the game manually, its difficult too.

This is nowadays often associated with Ai tools, but doesn’t have to. I’m not entirely sure, but the N64Recomp in example is such a non Ai recomp tool.

In general, the best case is that we have good high quality human readable and understood source code; Decompilation. On the other hand Recompilation is much faster to create.