High/Low level emulation

High-level emulation (HLE) and low-level emulation (LLE) refer to methods used when emulating components or entire systems. They're used to differentiate approaches to system implementations by how each emulator handles a given component; a higher-level emulator abstracts the component with the goal of improving performance on the host, sacrificing the thorough measures needed to guarantee the correct behavior. The simplicity of most classic consoles allow low-level emulation to be feasible, but the exponential increase of processing power in newer consoles has necessitated the need for abstraction. Because high-level emulation can often be seen as a simulation, BIOS dumps and other machine-specific code that would normally enter the legal gray area of backups are usually not required.

As an example, a console has a 3D graphics chip called by the CPU to render games. An accurate low-level emulator would use a software renderer to ensure that the component's output is 1:1 with the original console. However, the software renderer runs on the host's CPU, which isn't designed for 3D applications; performance will be sluggish if the CPU isn't powerful enough to handle accurate 3D rendering in realtime. Fortunately, modern 3D APIs can alleviate this problem by redirecting 3D computations to the host's GPU, so a high-level emulator will make calls to the host's graphics chip in order to render the game faster. And HLE doesn't just speed up 3D rendering, it can also act like components that don't require accurate emulation for the original software to properly use it. As another example, a console has a system management interface separate from the rest of the hardware that programs will call to in order to interact with the system, ranging from save files to configuration settings. Accurately emulating this as a discrete component would slow down the emulation severely for no real benefit, because this data can easily be given to the software without having to jump through all the hurdles taken by the original hardware. These two respective examples are demonstrated by most graphics-accelerated Nintendo 64 emulator plugins that target the Reality Display Processor, and Dolphin's handling of the Wii's Starlet co-processor.

Contrarily to popular belief, the idea behind HLE has been around for longer than N64 emulator UltraHLE first premiered. Some systems of the past can only be simulated on computers today as they were not designed with conventional hardware (i.e. a CPU, memory bank, video chip, etc.), but instead discrete circuits. UltraHLE did begin the discussion of whether or not HLE is a good approach for preserving hardware and how it responds. Today, the debate continues.

Comparison to traditional models

Compared to LLE, HLE has a very different set of design decisions and trade-offs. As the complexity of modern (fifth generation and above) video consoles rapidly increases, so does their computational power; more importantly, the difference in computational power to consumer PCs, which are the most common host systems for the emulators, has shrunk over time. Thus, the requirements on the quality of the emulated services increases, together with the difficulty of doing so. Hardware chips in consoles are usually extremely specialized towards specific functionality needed by games written for them, often in directions which are completely different from those taken by the hardware in an average PC machine. For example, 3D graphics might be realized by an extremely fast integer processor, coupled with the assumption of main system memory being the same as graphics memory, taking away the separate step of loading textures.

Emulating such an architecture programmatically on a PC, characterized by the emphasis put on floating-point operations, and specialized graphics hardware with memory separate from the system memory would be extremely difficult, especially taking into account the scarcity of documentation typical for specialized, proprietary hardware. Even if such an emulator could be created, it may be too slow for use. An HLE emulator would take the data to be processed, along with the operations list, and implement it using the means available on the host systems. Floating-point math and GPU operations could be performed natively. The result is not only a much better match with the host platform but often significantly better results, as floating-point computation yields higher quality graphics suitable for high-resolution displays available for PCs. It is important to note, however, that the difference in resolution, shading, or processing of graphics memory, sound, and others will change the output from the native machine environment that the emulator is trying to replicate. Other than being less authentic, in some cases, this could be undesirable, for instance rendering portions of the game that were not meant to be seen, making seams in textures more evident because of higher resolutions, bi-linear filtering pixel layers, and at worst will cause software to crash or not execute certain instructions due to interrupts not correctly handled because of HLE simulation.

Advantages and disadvantages of HLE

Among the advantages of HLE technique, chiefly are the ability to utilize the existing host facilities much better and more easily, the ability to optimize the results as the code and hardware improves, and much less or no work at all needed to achieve the desired end result, if an appropriate function is already provided by the host, as would be common in 3D graphics functionality. The progress of implementations is also much more independent of the detailed hardware documentation, instead relying only on the listing of possible functions available to the programmer, which is already provided by a software development kit available for each platform.

The disadvantages include much higher reliance on standardization among target applications and the presence of sufficiently high-level mechanisms in the emulated platforms. If there is no such mechanism, or applications fail to utilize it in one of the already supported ways, they will not work correctly, even if other, superficially similar applications function with no problems. Thus a significant amount of tweaks might be required to get all of the desired titles to run satisfactorily.

As a side-effect, HLE removes the common source of legality issues, by not requiring the users to provide it with the bootstrap software used by the original platform to create an environment for applications to run in. Because the emulator itself provides such environment, it no longer needs system ROMs, bootstrap cartridge images or other software obtained from a physical copy of the emulated system, a process which usually resulted in an unclear status in the light of copyright law.

HLE is easier to start and when optimized, can achieve great speed even on weaker hardware. But it does so by sacrificing authenticity. Also, the accuracy of HLE approach cannot be matched to proper LLE software. The speed of HLE is the greatest advantage, however, it is achieved by the simulations of the desired output, rather than a mathematically correct output timed properly. In many cases, a specific software can run 90% as close when compared to the emulated machine, and another case 50% or even 0% (may fail to boot or start) in the same emulator, because of software that depends on very precise timings or functions that do not output properly. In LLE, since the software is trying to replicate the original hardware chips down to the bugs and waits, most software should work bug-free and not break one another because of the extensive game-specific hacks and individual, sometimes per game tweaks that become necessary once an error is spotted in HLE. Thus, maintaining compatibility and accuracy on an HLE software that targets a machine that had many games released in its time, will prove much more work and testing of hundreds, sometimes thousands of individual software.

Future Outlook

As the console systems progress into more and more complexity, the importance of HLE approach increases. Modern (6th and 7th generation) video consoles are already far too complex and powerful to facilitate their emulation using the traditional approach. Additionally, some systems (notably Xbox 360) have themselves little more than a standardized PC operating system, making it wasteful to try to recreate the hardware using PC as the host machine. Thus, HLE increasingly becomes the only sensible approach.

The state of consumer-level PCs have also changed, newer computers are much faster than 20 years ago, and LLE is becoming possible at last for some of the very first consoles and CPUs that had to be emulated via HLE in the 90s. As a result, many emulators can opt for accuracy and cycle-accurate replication of the microchips which result in very precise software environments that can finally replace old consoles and computers. As well, Blueshogun, one of the developers of Cxbx, has stated that making an LLE Xbox emulator would be MUCH more ideal and feasible and he, along with others have been working on XQEMU, an LLE Xbox emulator that has been slowly making progress. However, HLE has found a new purpose in smartphones, handheld devices, and other electronic gadgets that have much lower specs than the average computer, and for these devices, the speed and simulated functionality translates to higher frame-rates.

Currently, since mid-2016 and already well into the year 2017, there is a strange synergy between Cxbx-Reloaded, a mainly HLE Xbox emulator, and XQEMU (and now xemu, by Matt Borgerson continuing much of the work done on XQEMU), a purely LLE emulator. For more details on which one would be the best for aspiring developers to work on check these Reddit threads with more links to other threads & many detailed comments by JayFoxRox, one of the contributors on XQEMU, with the explanations that XQEMU is the best-suited emulator for developers to focus on in terms of improving accuracy and portability: . JayFoxRox, a contributor to the open-source XQEMU emulator and regular commenter for that emulator's foundation and progress, has appeared at a Reddit thread stating the fact that many more original Xbox games have been able to get in-game and, in some cases, at decent speeds on XQEMU; in addition to more work on backend tooling and a dedicated wiki.

Hybrid Emulation Methodologies

Hybrid emulation combines HLE’s efficiency in simulating high-level functionality with LLE’s precision in replicating hardware behavior, making it ideal for complex, modern consoles. Hybrid approaches leverage HLE to emulate high-level system functions (e.g., operating system APIs) and LLE for critical hardware components, optimizing performance and accuracy. For example, Cxbx-Reloaded (primarily HLE) and XQEMU (LLE-focused) demonstrate a synergy for Xbox emulation, with developers like JayFoxRox noting XQEMU’s potential for accuracy and portability. This balance is crucial for systems like the Xbox 360, which resemble standardized PC architectures, reducing the need for full hardware emulation. Collaborative projects, supported by resources, drive progress in hybrid emulation, with contributors advocating LLE’s feasibility for precise replication where HLE falls short.

Virtualization and Resource Management

Virtualization technologies enhance emulation by optimizing resource allocation and isolation. Emulators like Yuzu utilize Device Mapping and System Memory Management Units (SMMU) to efficiently manage resources, mapping hardware directly to the emulated system for reduced overhead. Emulators isolate core logic from OS-specific APIs (e.g., Wayland, Metal, Android) by abstracting input, audio, rendering, and threading interfaces similar to Hardware Abstraction Layers (HALs).

File System Emulation and Abstraction

Emulators must handle how guest systems access storage, from game discs and hard drives to memory cards and save files. This is often accomplished through two primary methods: low-level virtualization or high-level abstraction.

• Virtual Disk Images (Low-Level Approach): LLE-focused emulators like Xemu often use virtual disk images (e.g., .qcow2 files) that function as a raw, emulated hard drive. The guest operating system formats and manages its native file system (like FATX) entirely within this container file. This approach offers high accuracy by replicating the block-level behavior of the original storage device but can be less convenient for users wanting to manage individual game files directly.

• File System Abstraction (High-Level Approach): Emulators like Xenia and RPCS3 intercept the guest's file system API calls. When a game requests to read a file from a proprietary format like an Xbox STFS container or a PS3 disk, the emulator translates that request into a standard read operation on the host's file system (e.g., reading from a simple folder on an NTFS or ext4 drive). This method is highly efficient, simplifies file management for the user (e.g., adding mods or DLC), and avoids the overhead of emulating an entire storage device. However, it requires reverse-engineering the guest's file system drivers and APIs, and inaccuracies in this translation can lead to compatibility issues.

Compatibility Layers

Compatibility layers bridge the gap between emulated software and modern host environments. Shims intercept and modify API calls, enabling compatibility across platforms by supporting old APIs in newer environments or vice versa. This allows emulated software to interact seamlessly with host hardware, critical for systems with proprietary APIs.

Rendering Advancements

Rendering techniques are pivotal for emulating modern consoles, balancing accuracy and performance.

• Hardware Rendering: Emulators increasingly adopt modular rendering backends, supporting Vulkan, OpenGL, D3D11/12, or Metal. This approach improves portability across platforms (including macOS and mobile), enables per-backend optimizations, and supports fallback options when hardware or drivers vary. Hardware rendering does not inherently imply high-level rendering — it can also operate at a low level, mimicking console-specific GPU behavior while still utilizing the host GPU for execution. This differs from software rendering, which fully emulates the GPU pipeline on the CPU. Hardware renderers are capable of emulating low-level operations while benefiting from GPU acceleration. Ubershaders, precompile shader variants to reduce runtime stutter, though they increase GPU load.
  • Accurate Pipeline Emulation: Xenia employs Render Target Views (RTV), Depth-Stencil Views (DSV), and Rasterizer-Ordered Views (ROV) to replicate Xbox 360’s rendering pipeline accurately.
• Compute Shader-Based Rendering: Projects like parallel-rdp, redream, MelonDS, and paraLLEl-GS use compute shaders for GPU-accelerated software rendering, offering high accuracy for unique console pipelines (e.g., Nintendo 64, Dreamcast). While compute shaders enhance control, they are GPU performance-intensive, especially at higher resolutions, as pioneered by Themaister.
• Multithreading for Software Rendering: Software rendering relies on the CPU for precise graphics emulation, useful for systems with unique pipelines (e.g., Nintendo 64), but it’s resource-intensive. Various emulators support this technique such as PCSX2, melonDS, DuckStation. Multithreading can be used to increase performance; this technique spreads rendering across CPU cores, boosting speed. Emulators like cen64, Angrylion RDP Plus (N64 plugin), PCSX2, and IBM-PC emulators such as 86Box, PCem, and DOSBox forks (e.g., for Voodoo emulation) support this. Software renderer multithreading differs from Vulkan API backend multithreading, which parallelizes draw calls in hardware rendering, leveraging Vulkan’s explicit memory management for better CPU efficiency. In other words, when the CPU wants to make something draw it has to issue a "draw call," which takes up CPU time. On older APIs this was nearly all done on one thread. Because different threads cannot easily share rapidly updated data, multi-threading would often cause synchronization overhead, limiting performance benefits. Vulkan avoids this by explicitly defining memory usage and dependencies, allowing draw calls to be distributed across threads more efficiently, which (usually) improves performance. [1]

Common rendering settings in emulators for accurate representation

Emulators often include specialized settings designed to enhance the accuracy of their representation of original console hardware. While these settings can improve visual fidelity and game behavior, they often come with a performance overhead due to the increased computational demands of precise emulation.

• CPU Readback After Render Target Resolving: This technique handles console-specific rendering requirements, such as CPU access to GPU-rendered data for effects like HDR or post-processing. Consoles like the Xbox 360 use unified memory architectures (e.g., eDRAM), allowing fast render target access. Emulators like Xenia and ShadPS4 implement readback resolve, copying GPU data to CPU memory mid-frame, which introduces performance overhead due to data transfer bottlenecks and synchronization issues. Xenia’s readback_resolve option, configurable in xenia.config.toml, is tagged for games requiring it in its compatibility list. ShadPS4’s early implementation is similarly hardware-demanding, impacting frame rates due to CPU/GPU load.
• Force CPU Blit Emulation: RPCS3's forces emulation of all blit and image manipulation operations on the CPU. [2]
• Allow Host GPU Labels: This RPCS3 setting allows the host GPU to synchronize directly with the emulated Cell Broadband Engine (PS3's CPU). By doing so, it exposes the "true state" of GPU objects (like textures and render targets) to the guest CPU. While this incurs a performance penalty due to increased synchronization overhead, it can effectively eliminate certain types of visual noise, flickering, and graphical glitches that arise from timing or state inaccuracies between the emulated CPU and GPU. [3]
• Strict Rendering Mode: This global rendering setting in RPCS3 enforces strict compliance with the PlayStation 3's graphics API specifications. It is designed to disable all rendering path shortcuts and optimizations that might otherwise improve speed or allow resolution scaling. While it can lead to degraded performance and overrides resolution settings, its primary purpose is to resolve rare cases of missing graphics or flickering by prioritizing enhanced compatibility and accuracy over speed and visual enhancements. [4]
• Strict Flushing/Auto Flush: (e.g., in RPCS3 for the PlayStation 3 and PCSX2 for the PlayStation 2) forces texture flushing more frequently than strictly necessary, ensuring texture data is consistently updated on the GPU. This can resolve issues like flickering or missing textures but may impact performance. [5]
• Clear Memory Page State: (e.g., in Xenia-Canary for the Xbox 360) ensures that memory pages, particularly those related to the eDRAM, are cleared precisely as the original hardware would. This can prevent severe visual anomalies such as "polygon explosions" or corrupted textures, though it can incur a performance penalty. [6]

Modern Dependencies, Advancements and Optimization Strategies

Modern emulators use up-to-date frontends, standards, compiler features, functions, libraries, and APIs to maximize performance and compatibility. Optimizations are critical for emulation to achieve playable performance. See sections such as PlayStation 3 emulators#Emulation issues or PlayStation 2 emulators#Emulation issues in Emulation General Wiki's individual system pages for more detailed information about system-specific problems and optimization solutions.

Emulators often include interpreters for CPU cores, executing guest instructions sequentially. Though slower than JITs, interpreters are useful for offering fallback mechanisms, debugging, edge case testing, and platforms without official JIT support (e.g., iOS or WebAssembly environments). PPSSPP and DuckStation implements an IR-based interpreter that constructs a lightweight IR without full recompilation, making it fast enough for use on restrictive platforms. Some systems, especially those with self-modifying code (SMC) or tight memory control, require accurate emulation of instruction cache behavior. DuckStation includes an optional ICache emulation mode that improves internal timing, aligning framerate and performance closer to real PlayStation hardware.

• Dynamic Recompilation: (sometimes abbreviated to dynarec or DRC) is a feature of some emulators, where the system may recompile some part of a program during execution. By compiling during execution, the system can tailor the generated code to reflect the program's run-time environment, and potentially produce more efficient code by exploiting information that is not available to a traditional static compiler. Future recompilers may offload tasks to compute shaders, leveraging GPU parallelism. Experimental efforts also explore using machine learning to guide recompilation heuristics or hot path prediction. Emerging trends in this space include the use of intermediate representation (IR) for aggressive ahead-of-time (AOT) optimizations and hybrid JIT-AOT strategies — for instance, compiling hot paths with LLVM and cold paths with a faster, lightweight JIT like Cranelift. JIT recompilers often maintain persistent caches to avoid redundant translations. These caches may; store translated blocks for re-use within a session, track memory protection and relocation, support serialization across emulator runs (e.g., disk pipeline cache), or use invalidation mechanisms to handle self-modifying code or DMA updates.
  • PCSX2 features two prominent JITs: the EE Recompiler for the Emotion Engine (MIPS) and microVU for the Vector Units, both optimized for x86-64 with AVX2 support.
  • Citra and Ryujinx use Dynarmic, a fast ARM-to-x86 recompiler with block linking and host code caching.
  • Cemu's PPCRecompiler was recently rewritten for performance and modularity.
  • LLVM is increasingly adopted as a backend to translate emulator IR to optimized native code, offering maintainability and reuse of compiler tooling at the cost of compile-time speed.
  • New approaches explore AsmJit for fast codegen, MLIR for structured IR optimizations, and libffi or dyncall for cross-platform dynamic call interfaces. On compatible architectures, some emulators (e.g., Yuzu) implement Native Code Execution, bypassing traditional JIT layers for even greater performance and reduced overhead.

• Fast Memory Access: Techniques like Fastmem, implemented in PCSX2, Yuzu, and Dolphin, optimize memory operations for significant performance gains by minimizing overhead and improving cache efficiency.
• Instruction Set Support: such as AVX-512 for RPCS3, improves emulation speed and performance on CPUs supporting advanced SIMD instructions.
• Compiler Optimization Techniques: Emulators increasingly use Profile-Guided Optimization (PGO), Link-Time Optimization (LTO), and ThinLTO to generate more efficient binaries.

• Platform-Specific Memory and I/O Optimization: Modern emulators use platform-specific APIs to allocate memory and optimize I/O performance. On Windows; functions like VirtualAlloc2 and MapViewOfFile3 provide fine-grained control over virtual memory regions. On Unix-like systems; emulators utilize POSIX functions such as mmap() for memory mapping and madvise() with flags like MADV_DONTNEED and MADV_REMOVE to provide hints to the kernel for more efficient memory handling. This is further enhanced by flexible context switching via the SysV ABI, allowing developers to tune low-level process behavior for emulation performance. For disk access; advanced I/O strategies like io_uring, epoll, and O_DIRECT reduce file I/O latency—particularly beneficial for systems with complex disc or disk streaming.

• Timing and Synchronization: Emulators must accurately replicate the timing behavior of the original hardware to maintain proper game speed, audio-video synchronization, and prevent glitches or input lag. This requires minimizing host OS scheduling overhead and achieving precise timing: On Windows; high-resolution timers like QueryPerformanceCounter() and timeBeginPeriod() are used to achieve consistent polling intervals and input capture. On Unix-like systems; functions like nanosleep() and scheduling policies such as SCHED_FIFO or SCHED_RR prioritize time-sensitive emulator threads. For RTC emulation; platform-specific time zone APIs like GetDynamicTimeZoneInformation (Windows) and localtime() (POSIX) are used.

• Telemetry and Debugging Frameworks: Emulators may use telemetry (Breakpad, Sentry) and profilers like Tracy or VTune to detect crashes or performance issues.

• Parallelization and Rollback Techniques: Modern emulators separate components like CPU/GPU/I/O into threads, and implement rollback netcode (used in RetroArch, DuckStation) for low-latency online play.

• Continuous Integration (CI) and Code Analysis Tools: CI platforms like GitHub Actions and GitLab CI are used for building and testing across OSes. Static analyzers (Coverity, Codacy, Clang-Tidy) and sanitizers (ASan, UBSan, TSan) catch bugs and maintain code quality.

• Localization and Internationalization: Emulators increasingly support full translation systems, plural forms and grammatical translations via tools like gettext, Qt Linguist, and Weblate.

• UI and Input Frameworks: SDL3 and Qt6 provide cross-platform GUI support with high-DPI rendering, haptics, and hotplug-friendly input backends.

• Data Handling: Emulators use streamable compression format, zstd, lz4, and lzma for efficient data handling, and savestate compression.

• Audio Handling: High-quality, low-latency audio is essential for synchronization and game feel. Emulators increasingly use Cubeb for cross-platform audio with backend switching (WASAPI, ALSA, PulseAudio). Features like real-time device switching, resampling, and audio thread safety improve consistency. On Windows, XAudio2 2.9 is used in some emulators for low overhead. Spatial audio and surround decoding (e.g., FreeSurround) are also integrated.

• Third-Party Libraries and Ecosystem Integration: Modern emulators depend on a broad ecosystem of third-party libraries for multimedia handling, I/O, GUI, and performance:
  • Multimedia: ffmpeg, libpng, libjpeg, freesurround, cubeb
  • Filesystem and archives: libzip, libchdr, lzma
  • Data processing: fmt, rapidjson, rapidyaml
  • CPU and system introspection: cpuinfo, xbyak
  • UI and platform tools: Dear ImGui, discord-rpc, SDL3, Qt6

Representative example: PCSX2’s third-party directory.

AI-Powered Enhancements

Main article: Shaders_and_filters#AI-powered_filters

AI upscaling (e.g., ESRGAN in the Moguri Mod) enhances texture resolution, while tools like RetroArch use "AI Service" for real-time text translation using OCR technology. Future AI optimization remains promising but unproven. See each Wiki Category Consoles, Computers and Arcade for individual dedicated system pages to see provided up-to-date listings and in-depth information on specific aspects like hardware features, peripheral support, compatibility and also enhancements features etc.

FPGA

Main article: FPGA

Main article: MiSTer

Web-Based and Cloud-Based Emulation

Main article: Emulators on browsers

Though it is not popular or not a current focus for the emulation community, cloud-based emulation could improve accessibility for low-spec users. However, legal and technical hurdles limit its near-term potential. Some emulation cores are compiled to WebAssembly (WASM) for use in browser-based emulators like Libretro Web Player and js-dos. While it may be limited in performance, these are useful for software outreach purpose.

Game engine recreations and source ports

Main article: Game engine recreations and source ports

Examples

The term HLE originates from UltraHLE, the first emulator for the Nintendo 64 console that ran commercial games. Initial discussion about HLE occurred to give context for the reasons behind some video games not functioning properly with the emulator.

Dolphin uses HLE for the Starlet co-processor and its various system functions, related to Wiimotes, networking, file access, USB, and the like but it retains low-level components for the CPU, GPU, and memory handling.

See also

• History of emulation
• Emulation accuracy

External links

• History of UltraHLE
• UltraHLE - Technical Information: an overview of low-level CPU emulation and high-level co-processor emulation in UltraHLE
• The Ultra High-level (UHLE) technique