FEX, Box64, Proton, DXVK: What Translation Layers Actually Do

2026-09-11 · Explainer

Affiliate disclosure: This guide contains affiliate links. As an Amazon Associate, we earn from qualifying purchases at no extra cost to you. Learn more.

Open any guide about running PC games on an Android handheld and you will be hit with six proper nouns in the first paragraph. Box64, Wine, DXVK, Turnip, Proton, FEX. Nobody explains them, because everybody writing these guides already knows, and the result is that most people set this stuff up by copying settings without any idea what they are adjusting.

The concepts are not hard. There are really only three jobs being done, and once you can tell which name does which job, every stack you will ever meet becomes readable.

The One Idea That Makes This Click

Two completely separate problems get solved by two completely separate kinds of software, and almost everyone mixes them up.

Problem one is the processor. A PC game is a pile of x86 instructions. Your handheld or phone has an ARM chip. Those are different languages, and something has to translate.

Problem two is the graphics API. A Windows game talks to Direct3D. Your device offers Vulkan, or on Apple hardware, Metal. Different language again, different translator.

These are independent. You can have a device that needs both, one, or neither. A Steam Deck needs neither translator for the CPU, because it is already x86, but it still translates graphics. An Apple Silicon Mac running a native ARM Windows game would need the graphics translation but not the CPU translation.

There is a third job, and it is the one people mistake for the other two: answering Windows API calls. That is what Wine does, and it is not translation in either sense above.

Keep those three jobs apart and the rest of this is straightforward.

Job One: Translating the Processor

These take x86 or x86-64 instructions and produce ARM instructions, usually compiling them as the program runs.

FEX and Box64 are the two you will actually meet on handhelds, and the practical difference is the host. FEX targets Linux and is the choice when the whole system is Linux, which is why ROCKNIX uses it. Box64 works on Android without a Linux distribution underneath, which is why the Android apps use it.

None of these is an emulator in the console sense. A console emulator has to simulate an entire machine, including its GPU, its sound chip and its timing quirks. These only translate CPU instructions and hand everything else to real hardware. That is why the performance cost is a fraction of what console emulation costs, and why a phone that struggles with a PS2 game can sometimes run a much newer PC game.

Doing the same job ahead of time

Everything in that table translates while the program runs. The alternative is to do the translation once, before you ever launch it, which is what the recompilation scene does. A static recompiler takes a console game's original machine code and emits C or C++, and you compile that into a normal native program. No translator is present at runtime, so there is no per frame cost at all. Our decomp vs recomp explainer covers the trade off, and the catch is coverage: it has to be done per game, by hand, over months.

AnyPS5 is the most interesting current example because it sits between the two ideas. It rewrites a PlayStation 5 executable into a native Linux or Windows binary ahead of time, then supplies reimplemented system libraries for the result to link against, which is the same job Wine does further down this page. As of late September 2026 it has published releases and has one verified game running start to finish, a 2D platformer, with a single row on its compatibility list.

ARM64EC is not a translator

You will see ARM64EC listed alongside these and it does not belong there. It is a Microsoft ABI, a calling convention, that lets native ARM64 code and translated x86-64 code sit in the same process and call each other directly.

It matters because of what it avoids. Without it, if a translated game calls into a support library, that library has to be translated too. With it, the library can be real ARM64 code running at full speed, and only the game itself goes through the translator. Wine's ARM64EC build is what makes projects like Madeira on the iPhone plausible at all.

Job Two: Translating the Graphics API

These take Direct3D calls and turn them into something your GPU driver understands.

DXVK is the one that changed everything. Translating Direct3D to Vulkan turned out to be not just workable but frequently faster than the original path, because Vulkan maps more cleanly onto modern GPU hardware than the older Direct3D versions did. It is a large part of why the Steam Deck works as well as it does.

Turnip shows up constantly in Android guides and is not a translation layer at all. It is an open source Vulkan driver for Adreno GPUs, an alternative to Qualcomm's official one. When a Winlator guide tells you to switch Turnip versions, you are changing the GPU driver underneath DXVK, not changing the translator. Our Winlator setup guide covers when that is worth doing.

Job Three: Answering Windows

Wine is neither of the above, and the old joke about its name is literally true: Wine Is Not an Emulator.

When a Windows game asks the operating system to open a file, create a window, play a sound or read a controller, it calls into Windows libraries. Wine provides its own implementations of those libraries. Nothing is being simulated and nothing is being translated. The call arrives, Wine answers it, the answer goes back.

Proton is Valve's Wine. It is Wine with DXVK and VKD3D-Proton bundled in, plus game-specific fixes and Steam integration. When people say "Proton" they usually mean the whole package rather than the Wine part.

This is why a Windows game on a Steam Deck is not being emulated in any sense. The CPU instructions are already native x86. Wine answers the Windows calls directly. Only the graphics get translated, and that translation is often free or better than free.

How Real Stacks Compose

Now the useful part. Here is what actually ships, in order.

Read that column on the right and you have the explanation for most performance arguments in this hobby.

A Steam Deck is doing one translation. An Android handheld with a newer, higher-benchmarking chip is doing two, one of which is the expensive kind. That is why the Deck wins comparisons it should lose on paper, and why a phone that beats it in Geekbench does not beat it in games.

It also explains the advice everyone repeats without justifying it. Native Linux builds are better because they remove a layer. Vulkan-native games skip DXVK. The reason 32-bit games are often worse on Android is that Box86 is carrying a heavier burden than Box64. Every one of these is the same observation: fewer layers, more frames.

DroidDeck, released in October 2026, is the cleanest Android example of this arithmetic in the wild. It skips the Wine layer that Winlator and GameHub rely on and uses Valve's ARM64 Proton against Valve's own ARM64 Linux Steam client, which is why it lands in the same row as ROCKNIX rather than the Winlator one despite being an ordinary Android app. We cover the setup and its Adreno requirement in DroidDeck on Android handhelds.

Notice that the layer count does not separate the two Android roads. Armada, DroidDeck, Winlator, GameHub and GameNative all land on two. The difference is which two. Proton is maintained by Valve and tested against the Steam library every day, while Wine is a general purpose compatibility layer being asked to do the same job, and that shows up as fewer surprises rather than more frames. Our comparison of all five works through where that actually matters.

The Layer Nobody Expected: Android on Linux

Every layer described so far answers the same question, which is how to run something built for x86 or for Windows on something that is neither.

In September 2026 Valve open sourced a layer that runs the other way. Lepton is the Android container behind the Android only games on Steam Frame, and it runs Android apps on Linux. Each app gets its own container, the process needs no root, and it can borrow pieces from the host system including Mesa graphics drivers and Vulkan layers rather than shipping its own.

It is deliberately not a general purpose Android environment. Valve built it to launch games and kept it to roughly that.

This matters here because it inverts a tradeoff that has shaped every buying decision in this space. Switching an Android handheld to Linux used to mean giving up the Android app library, which for retro players includes most of the good emulators. Armada's October 2026 build ships Lepton with an app store integration and, in the project's own words, dual screen support for Android recompiled games. The Linux option now runs the Android apps too.

And it explains why a native port is categorically different from any of this. When a game is decompiled and rebuilt for ARM, the layer count goes to zero. Our guide on decompilation and recompilation covers that path, which is slow and rare but produces results nothing here can match.

Why Apple Is the Awkward One

Every platform in this space settled on Vulkan. Apple did not, and Metal is the only graphics API on iOS and macOS.

The consequence is that Apple needs a parallel set of everything. Vulkan-targeting layers like DXVK are useless there, so the ecosystem needs DXMT for Direct3D and MoltenVK for anything that already speaks Vulkan. This is a real reason Mac gaming lagged for so long, and DXMT existing at all is largely down to 3Shain's work with CodeWeavers backing it since 2024.

The timing of what happens next is genuinely strange. Apple is removing its own CPU translation layer. Rosetta 2 is fully supported through macOS 27, and macOS 28 in autumn 2027 keeps only a reduced version for older games that depend on Intel frameworks. macOS 26.4 already began warning users.

So Apple is retiring the official x86 translator on the Mac in the same window that community projects are building an unofficial one for the iPhone. If you run old Intel Mac games, that clock is worth knowing about.

What This Means for Buying a Handheld

The practical takeaway is short.

If you mainly want PC games, buy something x86. It removes the expensive layer entirely and removes an enormous amount of compatibility guesswork with it. Our best PC gaming handhelds guide covers those.

If you want PC games on ARM hardware, the two things that matter most are RAM and cooling, not benchmark scores. You are running a translator, a Windows layer, a graphics translator and a game at once. 12GB is a meaningfully different experience from 8GB, and a fan is worth more than a slightly faster chip that throttles.

Our Snapdragon 8 Elite handhelds guide covers the current high end, and Linux vs Android handhelds covers the choice between the FEX and Box64 worlds.

If you mainly want retro consoles, none of this applies to you. Console emulation is a different technology with a different cost profile, and a cheap handheld handles it. Start with best retro handhelds instead.

Frequently Asked Questions

Is Wine an emulator?

No. Wine implements the Windows API so that Windows programs can call into it directly. Nothing is simulated. The confusion comes from Wine usually being bundled with something that is a translator, like Box64 or FEX, in the setups people meet it in.

What is the difference between FEX and Box64?

Both translate x86-64 to ARM64. FEX targets Linux and is used where the whole system is Linux, such as ROCKNIX or the Steam Frame. Box64 runs on Android without a full Linux distribution underneath, which is why Winlator and GameHub use it. Performance depends heavily on the specific game rather than one being universally faster.

Why is my game slower on a phone that benchmarks higher than a Steam Deck?

Because the Deck is doing less work. It runs x86 code natively and only translates graphics. The phone translates every CPU instruction as well, and then sustains that load in a chassis with no fan. Benchmark scores measure peak performance, and this workload is about sustained performance.

Is DXVK slower than running on real Windows?

Often not. Translating Direct3D 9 or 11 to Vulkan can be faster than the original path, because Vulkan maps better onto modern GPU hardware than older Direct3D versions do. Direct3D 12 through VKD3D-Proton is usually closer to break-even or slightly behind.

What is Turnip?

An open source Vulkan driver for Qualcomm Adreno GPUs, not a translation layer. It sits below DXVK. Android guides tell you to swap Turnip versions because driver bugs cause game-specific rendering problems, and a different version often fixes them.

Do translation layers work with anti-cheat games?

Generally no. Kernel-level anti-cheat does not function in these environments, and trying to defeat it is a reliable way to get your account banned. Treat multiplayer titles with anti-cheat as off the table.

Does using these layers require pirated games?

No, and we do not cover that. These layers run the games you already own. Proton runs your Steam library, Wine runs software you have licences for, and everything in this guide assumes that.

Related Reading

• ULTRAKILL Runs on a Stock iPhone Now. Cyberpunk 2077 Does Not.
• ROCKNIX and Native Steam on Android Handhelds
• Winlator Setup Guide
• Decomp vs Recomp: How Old Games Become PC Ports
• AnyPS5 Turns PS5 Games Into Native PC Binaries
• Suyu's Last Release Recompiles Switch Code to Native x86
• Can You Emulate on the Steam Frame?
• Linux vs Android Handhelds
• Best PC Gaming Handhelds
• DroidDeck: Real Steam on Android Handhelds Without Reflashing
• Armada vs DroidDeck vs GameNative vs GameHub
• Can Android Handhelds Run Recompiled Games?