It's not emulation. It's recompiled to the target device's native machine code. It also required a lot of additional low-level, per game programming to make stuff like graphics and sound work correctly.
Traditional emulators also recompile games to the target device's native machine code. It just happens dynamically at runtime, hence the name "dynamic recompiler" or "Just In Time recompiler".
This is just a static recompiler or ahead of time recompiler, except instead of directly targeting machine code, it's targeting C/C++ as a type of portable assembly. It basically just looks like a bunch of macros implementing the behaviour of powerpc instructions.
The recompiled result will preform nowhere near as good as a proper manual decompilation project, it's still baking in a huge number of quirks from PowerPC and the compiler they originally used, and will have noticeably worse performance. But, performance will usually be good enough, and it's easy to manually replace any bad code-gen that shows up as a bottleneck in profiles.
And while they did replace a bunch of graphics/audio code, they are still directly emulating a bunch of the original Xbox 360 Kernel and hardware.
As I understand it, standard emulation is not dynamic recompiling or jit, it is emulating and converting system calls in realtime. So the game calls a system function unique to the original platform, the emulator sees that call and makes a similar one (or multiple) in the language of the emulating system, and then returns the correct response back to the original call from the game.
Your understanding is incorrect. Applications (games) written for older gaming consoles all had to ship some native code, and were even typically entirely native code. These consoles were also typically not x86 or x86-64 based, so for a PC-targeting emulator to run applications written for these platforms, they do need to have recompiler or interpreter facilities.
They also do not necessarily need to hook and replicate syscalls, provided the user provides a dump of the system software (they just run the system software and make it load the game - the original syscall codes are then ran).
This extends even to the graphics hardware side once programmable shaders became a thing.
It’s a weird in between, IMO. I don’t think it’s fair to say it’s not emulation, because in most places the original architecture’s state is maintained and functions are hooked through macros like PPC_FUNC - the original source code is not fully ported to the host platform, but relies on a set of compile and runtime tricks which, well, emulate the properties of the guest. But yes, it’s not traditional emulation and things are gradually ported to be more “native” over time.
No. Way lower level. WINE runs native code and replaces library and system calls. This turns native code into C++ macros and then recompiles those into code. This is like a JIT with C++ as the IR. On the other hand WINE is not an emulator ;)
