If dolphin emulates the hardware...

[Delphinidae1]

...how can it run games at 60 fps and at higher resolutions than native? I mean, if it emulates the hardware, shouldn't it behave like the hardware? If you can run the game at 60 fps it's like you're emulating a better hardware or something. Can someone explain this? Thank you.

[MayImilae]

Magic~

Ok serious answer, since we're emulating the hardware, it's pretty simple to make the emulated hardware better. It would be nearly impossible to overclock a physical CPU to 2x performance, but if we want our emulated CPU to be 2x as fast, we just... can! Assuming the host CPU can handle it of course. In the case of higher than native graphics, for all of the hardware API backends (OpenGL, D3D, etc) the host GPU is performing the rendering for us. If we want the host GPU to render at higher resolutions, it's trivial, we can just tell it to render in higher resolutions, and it just will! Assuming it is within the capabilities of the host GPU of course. There *are* complexities with that (like how the GC/Wii share their GPU and CPU memory while modern systems don't) but we have work arounds for cases like that, like the texture cache system for EFB Copies.

[Delphinidae1]

Right! So you do emulate better hardware...that's awesome! Just out of curiosity, how hard would it be to implement a recompiler, like this one: https://github.com/rexdex/recompiler ? So instead of emulating the hardware, just turn the games to windows executables? Would there be advantages to doing this? Disadvantages? I can imagine it's probably much more difficult to do, otherwise we'd only have recompilers, not emulators.

[AnyOldName3]

Games for consoles often have weird stuff going on like self-modifying code, which can't be statically recompiled as making the same modifications to the new architecture's version of the code will probably just produce a mess that doesn't do anything useful. Additionally, stuff like the GPU and DSP co-processor will be sent data from the CPU that doesn't necessarily look like anything in particular until it gets there, so what they're doing can't be statically recompiled, and definitely needs emulation.

It's maybe possible that much larger chunks of CPU code can be recompiled statically, but there'll always have to be emulation of co-processors, and there'll probably always have to be emulation as a fallback for when we don't know enough about how a piece of code is used until we actually try and use it.

[JMC47]

It's not possible to do this with GameCube/Wii games because they run directly on metal and can have self modifying code.

[Delphinidae1]

But if it was possible to do it, would there be advantages? I mean, running the game without emulation should be faster, right? I'm just curious, not implying that I'm not happy with the emulator or anything, dolphin is awesome.

[AnyOldName3]

It might well be faster, but we're getting into the domain of sci-fi, so the debate isn't necessarily worth having. There might even be cases where it isn't any faster, though. Bytecode based languages (such as anything that runs on the JVM, like Java) sometimes do certain things faster than the equivalent code written in a natively compiled language, for example, because the JIT for that can perform very machine-specific optimisations that might not work on a very similar machine that wasn't identical. Bytecode is usually designed specifically to be interpreted and/or JITed, though, so these situations are far more likely than they would be in Dolphin.

[DrHouse64]

Emulation usually needs more CPU cycles than running native code to do the same thing, so yes.
Things will get more interesting on that part with PS3 / X360 / PS4 etc... because games run on an OS. RPCS3 already have an experimental AOT recompiler.
But, I highly doubt we will be able to recompile whole games to be playable on PC without emulation tho.

[Shonumi]

Funny everyone should mention trying to recompile and entire game, since that's the approach a recent XBOX 360 project has taken to get games running on Windows, as an x64 binary or something like that. So far, only homebrew demos work, but we'll see where that goes.

But there are a lot of hurdles to this approach, especially when large portions of a game's functionality cannot be HLE'd, or when code can be modified. Most modern consoles typically copy code from a read-only source (i.e. carts or discs) into RAM, which means it can be changed (though some consoles may protect certain portions of RAM by locking it down).

Other challenges involve determining what is code vs data (not always segregated for every console), and determining what code belongs to what processor. For example on the GC and Wii, you can load up customized instructions to the DSP, which has a different instruction set that the PowerPC CPU. You get something similar with the SNES and its SPC, and even trickier stuff with the Super Game Boy uploading code to be executed on the SNES' CPU.

So, very unlikely you'll ever get a .exe of any GC and Wii games out of Dolphin anytime soon (discounting the Pikmin executable hidden on the game disc). Any advantages would have to come out of how well the conversion goes when optimizing anything. Let's just say, it's easy to generate code that performs poorly, but takes a lot of effort to make it efficient.

[DrHouse64]

Now that you mention XBox, I'm curious if anyone ever tried to make a AOT recompiler for the very first XBox games, since emulation seems hard for many reasons.