d3d8to9: running Direct3D 8 games through a Direct3D 9 translation layer

A pseudo-driver, not a wrapper: it replaces the D3D8 entry point itself

d3d8to9 is described as a pseudo-driver module whose purpose is to improve compatibility and stability in games that use Direct3D 8 for rendering, by converting all API calls and low-level shaders to equivalent Direct3D 9 ones. The word pseudo-driver carries the technical meaning. It is not a translating shim sitting beside the game, and it is not an emulator. It provides the Direct3D 8 entry point itself, and the game calls into it believing it is talking to the driver, while the calls are re-expressed against Direct3D 9 underneath. The source layout makes that concrete. The file d3d8to9.cpp holds the definition of the main D3D8 entry point Direct3DCreate8, d3d8to9_base.cpp implements the IDirect3D8 interface including device creation, and d3d8to9_device.cpp implements IDirect3DDevice8 including the shader conversion. A separate header, d3d8types.hpp, declares the D3D8 types a developer would otherwise find in d3d8.h, and interface_query.hpp holds a table mapping D3D9 interface addresses to their matching D3D8 implementations.

Shader bytecode is the hard part, and it is where the D3DX dependency comes from

Converting a draw call is comparatively mechanical. Converting a pixel or vertex shader is not, because the source program arrives as bytecode assembled for a shader model D3D9 no longer exposes in the same form. The project handles this by disassembling and reassembling shaders, which is why the build instructions insist on the old standalone DirectX end-user runtime: the D3DX libraries used for disassembling and assembling the shaders are required, and the D3DX runtime is not part of a modern Windows install. That is the single hardest external dependency in the project and it is the one most likely to stop a first build. The payoff of doing it at all is stated plainly in the README, which says the conversion opens those games to new possibilities from proven modding tools written for Direct3D 9, and names ReShade specifically. A modding tool that injects into a Direct3D 9 renderer cannot see a Direct3D 8 game without something like this in between.

The exact translation claim, and the VSync paragraph that qualifies it

The README makes a precise claim and then immediately takes it back in a specific way, and the pair is worth reading together. The claim is that d3d8to9 does exact translation from Direct3D 8 to Direct3D 9 only. The qualification is that on recent versions of Windows, depending on system settings, GPU drivers and other factors, rendering behaviour in Direct3D 9 using d3d8to9 may differ from native Direct3D 8. The example given is VSync getting enabled with d3d8to9 even though it appears inactive in native Direct3D 8, despite the application enabling it. The project is careful about how it frames this: the behaviour may give an inaccurate impression of lower performance with d3d8to9, while it actually follows what the application requests. So the difference is attributed to the application and the modern driver stack, not to a mistake in the translation, which is a claim about the limits of the guarantee rather than an admission of a bug.

When to reach for dxwrapper instead

The README recommends a different tool for the behaviour questions, and the recommendation is specific. If you want to tweak the VSync behaviour, or force VSync off, it is recommended to use a separate tool such as dxwrapper, which uses d3d8to9 internally for the API call conversion but adds additional configuration opportunities. That is a useful division of responsibility to understand before installing anything. d3d8to9 is the conversion layer, and dxwrapper is the layer that exposes configuration on top of it. A user who wants only the ReShade capability installs d3d8to9 and is done. A user who wants to adjust renderer behaviour as well starts from dxwrapper and inherits the conversion from underneath. It also means that swapping either piece is not a decision you have to make alone, since one contains the other.

Building it: Visual Studio 2013 or newer, plus an SDK from 2010

The build requirements are old, which is the practical constraint for anyone trying this today. You need Visual Studio 2013 or higher to build d3d8to9, and it is recommended to install the old standalone DirectX end-user runtime, which is required for the D3DX libraries used for disassembling and assembling the shaders. The repository layout matches a Visual Studio project rather than a cross platform one. There is a d3d8to9.sln solution file, a d3d8to9.vcxproj project file and a matching filters file, a CMakeLists.txt, a res/ directory for resources, and the source/ directory holding the code the README walks through. The build itself is driven by the Visual Studio solution, with the CMake file as an alternative route, and the continuous integration badges show both GitHub Actions and AppVeyor configured for the project, which is a sign of a build matrix that spans two different CI systems.

Why this matters beyond one game: stability and compatibility, not just modding

The README's first sentence names two goals, compatibility and stability, and only the third one, the modding ecosystem, gets the ReShade example. The stability half is the quieter benefit. A Direct3D 8 game running on a modern Windows install is running a twenty year old graphics API and the usual outcome is that the game is limited to a fixed low resolution with no widescreen, or it fails to start at all. Translating to Direct3D 9 puts the game back on a path that current drivers still carry, which is what makes higher resolutions and modern display modes reachable in practice. That is the reason this class of tool keeps being written for each successive generation of games, and it is also why the project is licensed permissively enough for others to build on it.

Licence, releases and who to credit

All source code in the repository is licensed under a BSD 2-clause licence, with the text in the LICENSE.md file. That is one of the more permissive licences available, so forking and modifying the conversion is straightforward for anyone who wants to add a shader model or fix a device path that the current code does not handle. The release history shows a project that ships when it has something to fix: v1.13.0 on 2025-01-10, v1.15.1 on 2026-03-07 and v1.16.0 on 2026-09-23, with the last push to the repository on 2026-09-23, the same day as the newest tag. The version numbers in the 1.x series suggest a mature rather than a finished project, where the surface is stable and the changes are increments. The README also gives credit to the contributors who worked on compatibility, and singles out elishacloud, which is the author of the dxwrapper project it recommends in the VSync paragraph.

Editorial conclusion

d3d8to9 suits a player who wants to use a Direct3D 9 era modding tool on a game that shipped with Direct3D 8 and cannot be otherwise persuaded to use a newer renderer, and who is willing to accept that the translated rendering is not always identical to the original. It is the wrong tool if the game already runs on Direct3D 9, if you want to change the rendering behaviour rather than translate it, since the project is explicit that configuration work belongs in a wrapper such as dxwrapper, and a poor fit if you cannot install the old DirectX end-user runtime its shader assembler needs. Before building it, install Visual Studio 2013 or later and the standalone DirectX end-user runtime for the D3DX libraries, and read the VSync paragraph in the README so that an apparent performance drop is not mistaken for a translation defect.

Frequently asked questions

Official sources

1. crosire/d3d8to9 on GitHub
2. Issues
3. License: BSD-2-Clause
4. README
5. Releases