For four decades, the x86 instruction set has been the backbone of PC gaming. From the 8086 in IBM's first PCs to the Ryzen and Core processors powering today's rigs, x86 has been the constant. Every major game engine, every DirectX call, every Windows executable assumes it.
That assumption is now under strain.
ARM processors—the chips in your phone, your tablet, Apple's entire Mac lineup, and a growing wave of gaming handhelds—don't speak x86. They speak a different language entirely. And when you want to run an x86 game on ARM hardware, something has to translate. That something is x86 emulation.
It's a technical necessity, and it's also a mess. Performance drops. Games break. Compatibility layers stack on top of each other like scaffolding around a crumbling building. Developers and users alike have started calling it what it often feels like: a scourge.
Key Takeaway: x86 emulation is the bridge between two incompatible computing worlds. It works, but it extracts a toll in performance, compatibility, and complexity.
This article covers the full picture: what x86 emulation actually is, why it's so punishing for games, which tools exist, and whether the situation is improving. We'll move from DOSBox to Rosetta 2, from QEMU to FEX-Emu, and examine what the shift to ARM means for anyone who wants to play games built for a different architecture.
A CPU doesn't understand C++, Python, or even assembly language in the abstract. It understands machine code: specific binary patterns that map to operations the hardware can perform. The set of these patterns is the Instruction Set Architecture.
x86 (and its 64-bit extension, x86-64) is one ISA. ARM is another. They're not compatible. An ARM chip cannot execute x86 machine code any more than a French speaker can understand Mandarin without translation.
Virtualization runs code directly on compatible hardware. When you run a Windows VM on an Intel Mac, the guest code is still x86, and the CPU executes it natively. The hypervisor manages resources, but there's no instruction translation. Performance overhead is typically small—often under 5%.
Emulation is different. The host CPU cannot execute the guest's instructions. Every x86 instruction must be intercepted, decoded, translated into ARM instructions, and then executed. That translation costs time. Sometimes a lot of it.
Key Takeaway: Virtualization is a traffic cop directing compatible traffic. Emulation is a translator rewriting every sentence on the fly.
Early emulators interpreted instructions one at a time: fetch, decode, execute, repeat. That's slow—often 50-100x slower than native.
Modern emulators use dynamic binary translation. Instead of translating each instruction individually, DBT translates blocks of code at runtime, caches the results, and reuses them when the same code runs again. Loops and frequently executed functions get translated once and then run at much higher speed.
This is how QEMU, Rosetta 2, Box64, and FEX-Emu achieve usable performance. It's also why emulation performance varies wildly: code that translates well runs fast; code that doesn't—self-modifying code, unusual instruction patterns, tight timing dependencies—runs slowly or breaks entirely.
Games are among the hardest workloads to emulate. They combine:
A word processor can tolerate a 30% slowdown. A game running at 45fps instead of 60fps is a degraded experience. A game that crashes because of one unimplemented instruction is unplayable.
Emulation overhead varies enormously depending on the emulator, the workload, and the hardware.
| Emulator | Typical Overhead | Best Case | Worst Case |
|---|---|---|---|
| Rosetta 2 | 20-30% | ~10% | 50%+ |
| Box64 | 20-40% | ~10% | 80%+ |
| QEMU (TCG) | 200-500% | 100% | 1000%+ |
| FEX-Emu | 10-30% | ~5% | 50%+ |
These numbers are rough. A game that's GPU-bound might run fine under emulation because the CPU has headroom. A game that's CPU-bound—strategy titles, simulation games, anything with complex AI—will suffer badly.
Key Takeaway: There is no single "emulation penalty." It depends on the code, the emulator, and the hardware. But for games, even a 20% overhead can mean the difference between smooth and stuttering.
QEMU is a general-purpose emulator. It's not optimized for gaming. Its TCG (Tiny Code Generator) backend translates x86 to ARM, but without the aggressive optimizations found in gaming-focused emulators.
In practice, QEMU's x86 emulation on ARM can be 5-10x slower than native for CPU-intensive tasks. A game that runs at 60fps natively might run at 6-12fps under QEMU. That's not playable for most genres.
QEMU does support KVM acceleration—but only when the host and guest architectures match. On an ARM host, KVM can't accelerate x86 guests. You're stuck with TCG, and you're stuck with the slowdown.
Performance is only half the problem. The other half is correctness.
x86 is a sprawling ISA with decades of extensions: SSE, AVX, AVX-512, and countless vendor-specific instructions. Emulators implement the common ones first. The obscure ones come later—or never.
When a game hits an unimplemented instruction, it crashes. When it relies on precise timing—say, a game that uses CPU cycles for audio synchronization—emulation can introduce drift that causes glitches, desyncs, or audio artifacts.
Some games are also sensitive to memory ordering. x86 has a relatively strong memory model; ARM has a weaker one. Emulators must insert memory barriers to preserve x86 semantics, and those barriers cost performance.
Here's a common misconception: "Proton runs Windows games on Linux, so it must be emulation."
It's not. Proton is a compatibility layer. It translates Windows API calls (DirectX, Win32, etc.) to Linux equivalents (Vulkan, POSIX). The CPU instructions are still x86, running natively on x86 hardware.
On ARM, you need both: API translation (Wine/Proton) and CPU instruction translation (Box64, FEX-Emu, etc.). That's two layers of translation, each with its own overhead and its own bugs. The combination is where things get truly painful.
Key Takeaway: Running Windows x86 games on ARM Linux requires emulating the CPU, translating the graphics API, and reimplementing the Windows API. Three layers, three failure points.
DOSBox is the grandfather of gaming emulators. It emulates an x86 PC—typically a 486-class machine—along with Sound Blaster audio, VGA graphics, and DOS itself.
It's not fast by modern standards, but it doesn't need to be. DOS games were designed for hardware that's thousands of times slower than today's chips. Even with heavy emulation overhead, DOSBox runs them comfortably.
DOSBox's accuracy is its strength. It emulates timing quirks, undocumented instructions, and hardware oddities that modern systems have long forgotten. For game preservation, that matters more than speed.
QEMU emulates entire systems: CPUs, memory, storage, network interfaces, and peripherals. It can run x86 Windows on ARM, x86 Linux on RISC-V, and just about any other combination you can imagine.
For gaming, QEMU is a blunt instrument. It's not optimized for interactive workloads. But it's flexible, well-maintained, and often the only option for running older operating systems or unusual configurations.
Box86 and Box64 are purpose-built for running x86 Linux games on ARM. Box86 handles 32-bit x86; Box64 handles 64-bit x86-64.
They use dynamic binary translation with a focus on gaming workloads. They also integrate with native ARM libraries: when a game calls a system library, Box64 can redirect that call to the ARM version, avoiding translation overhead for non-game code.
On a Raspberry Pi 4, Box64 can achieve 70-80% of native performance for some games. That's not perfect, but it's often enough to be playable.
When Apple transitioned from Intel to Apple Silicon, it shipped Rosetta 2: a translation layer that lets x86-64 Mac apps run on ARM-based M-series chips.
Rosetta 2 is remarkably good. For many applications, the overhead is 20-30%. Apple achieved this through aggressive optimization, ahead-of-time translation of code that doesn't change, and deep integration with macOS.
For gaming, Rosetta 2 is a mixed bag. It handles older games and less demanding titles well. But modern AAA games—already pushing hardware limits—struggle. And games that rely on anti-cheat or low-level system access often refuse to run at all.
FEX-Emu is a newer entrant focused on high-performance x86 emulation on ARM64 Linux. It's used in projects like the AYN Odin handheld and is actively developed.
FEX-Emu claims near-native performance for some games, with overhead as low as 10-20% in ideal cases. It achieves this through aggressive block caching, register allocation optimization, and integration with ARM's native libraries.
It's not magic. Demanding games still struggle. But FEX-Emu represents the current state of the art for open-source x86 emulation on ARM.
Key Takeaway: The best emulators for gaming—Box64, FEX-Emu, Rosetta 2—achieve 70-90% of native performance in good cases. That's impressive, but it's still a significant tax.
ARM chips dominate mobile devices because they're power-efficient. They deliver acceptable performance per watt, which matters when you're running on a battery.
Apple's M-series chips proved that ARM can compete with x86 on raw performance too. The M1, M2, and M3 chips trade blows with Intel and AMD's best in many workloads, often while using less power.
For gaming handhelds, ARM is attractive for the same reason: battery life. Devices like the AYN Odin, Retroid Pocket, and Anbernic RG series use ARM chips. They're not as powerful as x86 handhelds like the Steam Deck, but they're smaller, lighter, and last longer.
The Steam Deck is an x86 device. It runs x86 games natively. But it still uses Proton to translate Windows API calls to Linux.
This is worth clarifying because it's often confused with emulation. Proton doesn't translate CPU instructions. It translates system calls and graphics APIs. The performance overhead is much lower than CPU emulation—often negligible for well-optimized games.
The Steam Deck proves that API translation can work well. It doesn't prove that CPU emulation is easy.
Handhelds like the AYN Odin run Android on ARM chips. To play x86 games, they rely on emulators like Box64 or FEX-Emu, often combined with Wine or Proton.
The results are mixed. Older games and indie titles often run well. Modern AAA games are out of reach. But for emulation enthusiasts, these devices offer a portable way to play a huge library of older PC games.
Cloud gaming services like GeForce Now and Xbox Cloud Gaming run games on x86 servers. The client device—whether it's an ARM phone or an x86 PC—just streams video.
This sidesteps the emulation problem entirely. The heavy lifting happens on x86 hardware in a data center.
But some companies have experimented with ARM servers for cloud gaming. The appeal is cost: ARM servers can be cheaper to run. The challenge is the same as on-device emulation: performance and compatibility.
For now, x86 remains dominant in cloud gaming. ARM servers are a niche experiment, not a mainstream solution.
Key Takeaway: ARM is winning in mobile and handhelds. But for gaming, x86 still rules—and emulation is the bridge between them.
Games are cultural artifacts. They deserve to be preserved and played.
But PC games are fragile. They depend on specific operating systems, hardware configurations, and APIs that no longer exist. A game designed for Windows 95 might not run on Windows 11. A DOS game might not run on modern hardware at all.
Emulation is often the only way to keep these games alive. DOSBox preserves thousands of DOS titles. PCem and 86Box emulate older x86 hardware for games that DOSBox can't handle. Virtual machines run Windows 95, 98, and XP for games that need them.
Without emulation, large swaths of gaming history would be lost.
Here's a scenario: You bought a game in 1998. You still have the CD. You want to play it on your M2 Mac.
Without emulation, you can't. The game is x86. Your Mac is ARM. The operating system it expects no longer exists. The APIs it calls have been deprecated.
Emulation lets you run the game you legally own on hardware that was never designed to run it. That's not piracy. That's preservation.
Emulators are legal. Courts have consistently ruled that emulation is a legitimate technology, not a tool for piracy.
ROMs—copies of games—are a different matter. Downloading a ROM for a game you don't own is copyright infringement. Downloading a ROM for a game you do own is a legal gray area that varies by jurisdiction.
For x86 games, the situation is usually simpler: you own the game, you run it under emulation. No ROMs involved. Just translation.
Emulation doesn't happen by accident. It's the work of volunteers, hobbyists, and open-source developers who spend thousands of hours reverse-engineering hardware, documenting obscure behaviors, and writing code that makes old games run.
Projects like DOSBox, Box64, and FEX-Emu are community-driven. They rely on donations, contributions, and the stubborn belief that old games deserve to be playable.
Key Takeaway: Emulation is preservation. Without it, thousands of games would be unplayable on modern hardware—not because they're lost, but because the systems they need no longer exist.
Dynamic binary translation is getting better. Modern emulators use profile-guided optimization, adaptive block caching, and JIT compilation techniques borrowed from language runtimes.
Hardware acceleration is also helping. Some ARM chips have instructions that map cleanly to x86 operations, reducing translation overhead. GPU compute can offload some translation work. These techniques are still experimental, but they point toward a future where emulation overhead is lower.
The best way to run an x86 game on ARM is to not run x86 code at all. Native ARM ports eliminate emulation entirely.
Some developers are doing this. Games like Control, Metro Exodus, and Resident Evil Village have native ARM versions for Apple Silicon. They run faster and more reliably than emulated x86 versions.
But native ports require developer effort. For older games, the source code may be lost. For smaller titles, the economics don't work. Emulation will remain necessary for the long tail of gaming history.
The most promising approach combines API translation (Wine/Proton) with CPU emulation (Box64/FEX-Emu). This is what makes ARM gaming handhelds viable.
The API layer handles Windows and graphics calls. The CPU layer handles x86 instructions. Together, they let x86 games run on ARM hardware with acceptable performance.
This hybrid approach is still maturing. Bugs are common. Performance varies. But it's improving, and it's the most practical path forward for running x86 games on ARM.
No. Not completely.
Emulation will always have overhead. Translation will always introduce bugs. The gap between x86 and ARM is fundamental, and no amount of engineering can eliminate it entirely.
But the scourge can be managed. Emulators are getting faster. Compatibility is improving. For many games, emulation is already good enough.
The goal isn't perfection. It's playability. And for a growing number of games, emulation delivers that.
Key Takeaway: x86 emulation on ARM will never be free. But it's getting cheaper, and for many games, the cost is now acceptable.
What is x86 emulation in gaming?
x86 emulation is the process of running software compiled for x86 processors on non-x86 hardware, such as ARM-based devices. In gaming, it allows x86 games to run on ARM handhelds, Apple Silicon Macs, and other non-x86 systems.
Why is x86 emulation considered a "scourge"?
The term reflects the frustration of dealing with performance penalties, compatibility issues, and complexity. Emulation often results in lower frame rates, crashes, and glitches. For users who just want to play games, it can feel like an endless battle against technical problems.
What are common x86 emulators used for gaming?
DOSBox (for DOS games), QEMU (general-purpose emulation), Box86/Box64 (x86 Linux games on ARM), Rosetta 2 (x86 Mac apps on Apple Silicon), and FEX-Emu (high-performance x86 emulation on ARM64 Linux).
How does x86 emulation affect game performance?
Performance overhead ranges from 20% to over 80%, depending on the emulator and the game. CPU-intensive games suffer more. GPU-bound games may run acceptably if the CPU has headroom.
Can x86 emulation run modern AAA games?
Rarely well. Modern AAA games push hardware to its limits, and emulation overhead makes them unplayable in most cases. Older games and indie titles fare much better.
Is x86 emulation legal?
Yes. Emulators are legal. The legality of ROMs depends on whether you own the original game and your jurisdiction's laws. Running legally owned software under emulation is generally legal.
What is the difference between x86 emulation and virtualization?
Emulation translates instructions from one architecture to another. Virtualization runs code directly on compatible hardware. Emulation is slower but works across architectures; virtualization is faster but requires matching architectures.
Why is x86 emulation important for game preservation?
Many older games depend on x86 hardware and operating systems that no longer exist. Emulation allows these games to run on modern hardware, preserving them for future generations.
What are the alternatives to x86 emulation for running x86 games on ARM?
Native ARM ports (when available), cloud gaming (streaming from x86 servers), and hybrid approaches combining API translation with CPU emulation.
How does Rosetta 2 compare to other x86 emulators for gaming?
Rosetta 2 is polished and well-optimized for general applications, with 20-30% overhead in many cases. For gaming, it's less consistent—some games run well, others struggle or refuse to run due to anti-cheat or low-level system access.
x86 emulation is a necessary evil. It exists because the computing world is fragmenting, and games are stuck in the middle.
It's not pretty. Performance drops. Games break. Compatibility layers stack up like debt. But without emulation, huge parts of gaming history would be inaccessible on modern hardware.
The situation is improving. Emulators like Box64, FEX-Emu, and Rosetta 2 are pushing performance closer to native. Hybrid approaches combining API translation with CPU emulation are making ARM gaming handhelds viable. Native ARM ports offer a way out for some games.
But the scourge won't disappear. The gap between x86 and ARM is architectural, not incidental. As long as both exist, emulation will be needed.
The goal isn't to eliminate emulation. It's to make it good enough that most people don't notice the seams. For many games, we're already there. For others, there's still work to do.
Key Takeaway: x86 emulation is a bridge, not a destination. It lets us play games from a different architectural era on hardware that was never meant to run them. That's worth the cost—even if the cost is high.
Dive deeper into the world of x86 emulation: share your experiences with emulators like Box64 or Rosetta 2 in the comments, and explore our guides on optimizing emulation performance for your favorite retro and modern games.