4 ms·

Early emulators had to emulate the super funky hardware that early consoles had. Now a days consoles are pretty similar to consumer computers (I though the swi

by geokon 3y ago

Early emulators had to emulate the super funky hardware that early consoles had. Now a days consoles are pretty similar to consumer computers (I though the switch was basically a Nvidia Jetson) Is the emulation now more like Wine - about providing the necessary APIs and then running on a VM, or is there actual hardware emulation ?

grishka 3y ago
It's more high-level than it used to be but GPU is the main problem. The graphics APIs that games use usually expose various hardware specifics so games could be fine-tuned to get most out of that specific hardware. It takes a lot of work to translate these hardware-specific API calls into OpenGL/Direct3D/Vulkan/Metal.
- zirgs 3y ago
  It helps that many console devs don't bother with low-level optimisations, because they can get away with a bit worse performance. Just cap the framerate to 30 like most other console games do. It wasn't an option during the NES era. Every clock cycle counted back then.
  - deleted 3y ago
    [deleted]
  - grishka 3y ago
    NES-era games also ran on bare metal. Modern consoles run proper modern operating systems with everything you'd expect to find in one — preemptive multitasking, virtual memory, hardware abstractions, kernel- and user-mode with syscalls, etc. PlayStation OS is a Unix system (something-BSD IIRC), Xbox's is obviously based on Windows NT, and Switch runs something Nintendo built from scratch. Cycle-counting doesn't make much sense for code running in a preemptive-multitasking OS because no matter how much you count cycles, the actual execution time for a piece of code would be non-deterministic. That, and I suppose most modern games are bottlenecked by the GPU, not the CPU.
    - Retr0id 3y ago
      fwiw, the switch actually uses cooperative multitasking. This causes emulation headaches of its own, because sometimes retail games are buggy, but due to the relative determinism of scheduling nobody ever noticed (e.g. race conditions that are reliably won on real hardware will suddenly start breaking in emulation).
      - grishka 3y ago
        Cooperative multitasking on a multi-core CPU? How on earth does that work? Do games themselves assign their threads to cores explicitly?
bakugo 3y ago
For the Switch specifically, it has an ARM CPU so an ARM emulator is still necessary on x86 systems, but on native ARM systems it's possible to run CPU code almost natively, and this has already been done (a now-dead emulator for android called Skyline did it, and apparently Yuzu will also implement this feature in the future) The bigger problem is the GPU, it's an Nvidia Maxwell GPU but uses its own custom API made specifically for the Switch (internally named NVN) so a full translation layer including shader recompilation is still necessary.

by geokon 3y ago

grishka 3y ago

It's more high-level than it used to be but GPU is the main problem. The graphics APIs that games use usually expose various hardware specifics so games could be fine-tuned to get most out of that specific hardware. It takes a lot of work to translate these hardware-specific API calls into OpenGL/Direct3D/Vulkan/Metal.

zirgs 3y ago
It helps that many console devs don't bother with low-level optimisations, because they can get away with a bit worse performance. Just cap the framerate to 30 like most other console games do. It wasn't an option during the NES era. Every clock cycle counted back then.
- deleted 3y ago
  [deleted]
- grishka 3y ago
  NES-era games also ran on bare metal. Modern consoles run proper modern operating systems with everything you'd expect to find in one — preemptive multitasking, virtual memory, hardware abstractions, kernel- and user-mode with syscalls, etc. PlayStation OS is a Unix system (something-BSD IIRC), Xbox's is obviously based on Windows NT, and Switch runs something Nintendo built from scratch. Cycle-counting doesn't make much sense for code running in a preemptive-multitasking OS because no matter how much you count cycles, the actual execution time for a piece of code would be non-deterministic. That, and I suppose most modern games are bottlenecked by the GPU, not the CPU.
  - Retr0id 3y ago
    fwiw, the switch actually uses cooperative multitasking. This causes emulation headaches of its own, because sometimes retail games are buggy, but due to the relative determinism of scheduling nobody ever noticed (e.g. race conditions that are reliably won on real hardware will suddenly start breaking in emulation).
    - grishka 3y ago
      Cooperative multitasking on a multi-core CPU? How on earth does that work? Do games themselves assign their threads to cores explicitly?

bakugo 3y ago

For the Switch specifically, it has an ARM CPU so an ARM emulator is still necessary on x86 systems, but on native ARM systems it's possible to run CPU code almost natively, and this has already been done (a now-dead emulator for android called Skyline did it, and apparently Yuzu will also implement this feature in the future) The bigger problem is the GPU, it's an Nvidia Maxwell GPU but uses its own custom API made specifically for the Switch (internally named NVN) so a full translation layer including shader recompilation is still necessary.