That distinction is especially important around Need for Speed Underground 2. The project’s own hardware-status reporting says the game has reached in-game play on real Switch hardware with sound and controller support, alongside a reported performance range of roughly 20 to 45 frames per second at default detail with the CPU overclocked. It is a meaningful demonstration, but it is not an independently reproduced benchmark and does not establish a broadly reliable experience for every Switch, game copy, or race.
What “runs on Switch” means here
Wine-NX is described as a port of Wine 11 intended for the Switch’s Horizon OS homebrew environment. Its purpose is to run Windows programs on the console without placing a Linux/L4T installation underneath the application and without sending game video from a separate PC through streaming.
That makes “directly on Switch” a reasonable description only if it refers to where the runtime is operating. It does not mean that an original x86 Windows executable is running natively on the Switch processor. The Switch uses an ARM-based platform, whereas the targeted Windows applications use x86 code.
For 32-bit x86 programs, the compatibility approach combines Wine’s newer WoW64 architecture with Box64’s ARM64 dynamic recompiler. Wine provides the Windows API compatibility layer, while Box64 translates x86 application code for execution on ARM64. The resulting stack must deal with translated CPU instructions, Windows application behavior, graphics handling, input, audio, and the constraints of a console homebrew environment at the same time.
That complexity is why successful launches matter, but it is also why each result should be treated as title-specific. A game can encounter problems in its translated code, its Windows API expectations, its graphics path, its timing behavior, or an interaction among several of those layers.
The Need for Speed Underground 2 report
The project maintainer’s hardware-status material is the basis for the reported Need for Speed Underground 2 outcome. According to that project reporting, the game runs in-game on real Switch hardware with sound and controller support. The same maintainer status table reports approximately 20–45 fps in races at default detail with CPU overclocking.
Those figures need unusually careful framing. They are maintainer-reported hardware-status results, not independently reproduced performance measurements. The available project material does not establish a repeatable benchmark procedure, the full clock configuration, the specific Switch revision, thermal conditions, race selection, test duration, or frame-time consistency. A wide range also cannot, by itself, answer the practical question of whether control response and pacing remain consistent in different races.
The game reportedly has a notable memory-layout requirement. Wine-NX documentation says Underground 2 needs a 32-bit “no alias” NRO forwarder configuration because the game uses a fixed-base address space. The project further says that this configuration raises the available memory limit to 2 GiB.
That sort of application-specific requirement is revealing. It does not diminish the accomplishment of reaching playable in-game behavior, but it does distinguish an experimental compatibility environment from a general-purpose launcher that can be expected to handle a conventional Windows game library with little per-title work.
The sensible conclusion is narrow: the maintainer reports a playable result in a defined experimental setup. It is not evidence that every copy or configuration of the game, every hardware situation, or every gameplay scene will perform the same way.
The reported OpenTTD result and the Quake III path
The project maintainer’s hardware-status table also reports that OpenTTD 15.3 reaches up to 60 fps with OpenGL and sound. As with the Need for Speed Underground 2 figure, that is a project-maintainer result rather than an independently reproduced benchmark. It should not be treated as a general performance promise for Wine-NX or for Windows games on Switch.
OpenTTD also has a different technical profile from a Direct3D-era commercial racing game. A reported result in one application does not demonstrate comparable compatibility, performance, or input behavior in another.
The current repository documentation confirms a packaging path for a Quake III engine. It does not, however, establish the previously circulated specific Quake III Arena/Quake3e frame-rate result. Without a currently accessible maintainer post documenting that measurement or an independent reproduction, there is no reliable basis for presenting a precise Quake III benchmark figure.
This is more than a technicality. Early projects often accumulate screenshots, short demonstrations, and isolated performance claims that outlive the context in which they were produced. For readers trying to decide what to expect on their own hardware, a documented packaging route and a repeatable performance test are materially different kinds of evidence.
WarCraft III remains at an earlier stage
The current primary project status for WarCraft III is more limited than descriptions based on earlier work-in-progress notes. The repository says the game loads its game DLL and creates a Direct3D 9 device. It also identifies DirectShow support as still needed for the game’s intro movies.
Those are meaningful technical milestones: loading the relevant game component and creating a Direct3D 9 device show progress through important parts of the Windows and graphics initialization path. But they are not evidence of a complete or playable game implementation. They do not establish working menus, campaigns, gameplay, cutscenes, audio, or broader compatibility.
The distinction illustrates why compatibility reporting needs to be precise. A title may initialize a graphics device yet still stop at a later subsystem, such as media playback. Conversely, a visible title screen or game window would not necessarily show that input, gameplay logic, video playback, saving, sound, or stability are ready. For an experimental compatibility project, those individual checkpoints are useful engineering status updates, not consumer-readiness guarantees.
Graphics, input, and runtime limits
Wine-NX’s documented graphics path helps explain why results will vary. The project uses Mesa 20.1’s nouveau driver for OpenGL and routes Direct3D 9 through WineD3D. Vulkan is not currently supported.
For a Windows title using Direct3D 9, rendering does not follow a dedicated native Switch game path. It goes through Wine’s graphics translation layer while Box64 is also handling x86 instruction translation. That gives developers a route to test older Windows software, but it also creates multiple possible failure points and performance constraints.
The project documents touchscreen support and mappings that allow controller controls to serve mouse and keyboard functions. It can expose player one as an Xbox 360 controller through XInput, and its audio support is based on the Switch audout capability. These are substantial requirements for making a launched program usable on a handheld console rather than merely displaying a window.
Even so, the operational boundaries remain significant. The documented setup handles one program at a time and one controller. First-run Wine setup and COM registration are incomplete. Those limitations may be understandable during active development, but they matter for users expecting straightforward game switching, flexible local multiplayer support, and transparent application setup.
Why availability should be described cautiously
Build and packaging instructions are not proof of a stable end-user release. The available documentation does not establish a current, supported public binary release, a maintained installation path for nontechnical users, or broad compatibility across Windows applications.
That uncertainty changes the practical reading of every reported success. On a typical Windows PC, testing a game under Wine often begins with the game’s graphics APIs or runtime configuration. With Wine-NX, the question comes earlier: whether the user has an eligible Switch homebrew environment, whether the runtime can be built and packaged appropriately, whether a title is among the tested cases, and whether it needs special memory, graphics, input, or media support.
The reported Underground 2 result also involved CPU overclocking. Even if another technically capable user reproduces it, that would not automatically describe a stock-console experience. The available evidence does not support conclusions about battery behavior, heat, long-session stability, or how performance varies across Switch hardware revisions.
For Windows enthusiasts and preservation-minded readers, Wine-NX’s immediate value is that it demonstrates another compatibility route: Wine and x86 translation operating within the Switch homebrew environment rather than on a conventional desktop operating system. For players seeking a dependable way to access an existing PC library on a handheld, the evidence still falls well short of a substitute for a Windows PC, a conventional handheld PC, or established native ports.
Custom firmware is an eligibility boundary
Wine-NX requires a Switch that can launch custom firmware and homebrew. Whether a device can do that is not accurately captured by saying that it is simply an “older” Switch. Current community guidance distinguishes unpatched units that can use the RCM route from patched and Mariko systems that require a modchip, and advises checking model and serial information.
That requirement limits the audience for the project and introduces a separate consumer-risk question. Nintendo describes modchips and related products as circumvention devices that bypass console security measures. It warns that such hardware can void a warranty, reduce functionality including online play, or leave a console unable to work after network updates.
Those statements are not a jurisdiction-specific determination of an individual user’s legal situation. They are, however, relevant warnings from the platform holder. The technical appeal of Wine-NX should be considered separately from the consequences of modifying or maintaining the hardware needed to experiment with it.
A real experiment, not a finished platform
Wine-NX has crossed an important threshold: it shows that selected Windows software can be brought into the Switch homebrew environment through Wine’s WoW64 design and Box64 translation. The maintainer-reported Need for Speed Underground 2 and OpenTTD results are promising demonstrations, provided their status as project hardware-table reports—not independently validated benchmarks—remains clear.
The limitations are equally important. Original x86 code is translated rather than natively executed; Direct3D 9 follows a WineD3D path; Vulkan is unsupported; Underground 2 needs title-specific memory configuration; one-program and one-controller constraints remain; and WarCraft III is presently documented at the game-DLL and Direct3D-device stage, with DirectShow still required for intro movies.
The fairest assessment is neither that Windows games now broadly run on Nintendo Switch nor that Wine-NX is insignificant. It is an early compatibility effort with credible engineering milestones and a limited, evolving tested set. Its most meaningful future signs of maturity would be reproducible results, clearer supported packaging, broader application validation, and fewer game-specific workarounds.