ReShade: a generic post-processing injector for games and video software

What ReShade solves, and for whom

Games and video applications do not expose their rendered frame or their depth buffer to outside code. ReShade exists to give that access in a uniform way: it exposes both frame color and depth information and a shader language called ReShade FX, so effects such as ambient occlusion, depth of field and color correction can be written once and applied in many applications. The README's own framing is that these effects "work everywhere", which in practice means across the graphics APIs the project hooks rather than across every operating system or every title.

The audience the repository addresses is narrower than the download page implies. The build section opens with a hard requirement: Visual Studio 2017 or higher, plus Python in the PATH environment variable for the glad dependency. The solution layout (ReShade.sln, ReShade.vcxproj, ReShadeFX.vcxproj, ReShadeFXC.vcxproj, ReShadeInject.vcxproj) is a Visual Studio arrangement, and the source tree is C++. If you want to write an add-on, the README points at REFERENCE.md for the ReShade API, and the examples directory holds eighteen numbered sample projects. If you only want to apply an effect that someone else wrote, you are a user of the released setup tool rather than of this repository.

How the injector and the ReShade FX compiler fit together

The repository splits into two pieces that are worth keeping separate in your head. The first is the runtime. According to the README's file table, dll_main.cpp is the main entry point, hook.cpp wraps MinHook and tracks associated function pointers, and hook_manager.cpp performs automatic hook installation based on DLL exports. That pairing explains the design: hooks are not hardcoded per game, they are discovered from what a module exports. runtime.cpp holds the core runtime including effect and preset management, and runtime_gui.cpp covers overlay rendering and the user interface.

The second piece is the shader toolchain. effect_lexer.cpp is a lexical analyzer for C-like languages, effect_parser_stmt.cpp parses the ReShade FX language, and effect_preprocessor.cpp implements a C-like preprocessor. The README states that this compiler is standalone and can be integrated into other projects by adding all source/effect_*.* files and using it in the manner of the fxc example in tools/fxc.cpp. That is the most reusable part of the codebase and the least discussed.

Add-ons are the extension path. They are DLLs that use the ReShade API to extend ReShade or the application it is applied to. The examples directory shows the range the API is meant to cover, from a frame rate limiter (01-fps_limit) and 02-freepie to shader dumping and replacement (05-shader_dump, 06-shader_replace), texture dumping and replacement (07-texture_dump, 08-texture_replace), depth access (09-depth), swapchain override (16-swapchain_override) and window transparency (18-window_transparency).

Building ReShade from source on Windows

The README gives a three-step build. First clone with submodules, because the dependencies live there. The command is quoted directly from the README:

git clone --recurse-submodules https://github.com/crosire/reshade

Second, open the Visual Studio solution. Third, select either the 32-bit or 64-bit target platform and build. The README notes that this builds ReShade and all dependencies together. If you want the setup tool as well, the order matters: build the Release configuration for both the 32-bit and 64-bit targets first, and only afterwards build the Release Setup configuration, and the target selected at that point does not matter.

The Python requirement is easy to miss. The README says Python must be in the PATH environment variable for the glad dependency to build. There is no documented CMake-only path in the README even though a CMakeLists.txt sits at the top level; the build instructions describe the Visual Studio route exclusively.

For the standalone compiler, the integration is a file copy rather than a package install. Add all source/effect_*.* files to your project and follow the pattern of tools/fxc.cpp. There is no published package name to install from in the README, so treat this as source-level vendoring.

Where ReShade is the wrong tool

The mechanism is the limitation. ReShade installs hooks into another process's rendering calls, which means it depends on the shape of that process. hook_manager.cpp performs automatic hook installation based on DLL exports.

There is also a hard platform boundary in what the repository documents. The build instructions name Visual Studio and the project files are .vcxproj and .sln. Nothing in the README documents a Linux or macOS build path, so treating ReShade as a portable post-processing layer is not supported by what the repository says.

Finally, the documentation surface is thin in specific places. The README explains how to build and what the source files contain, and REFERENCE.md is the API reference for add-ons, but the README does not document rollback of an injection, nor how to remove hooks cleanly from a running process. If you need a post-processing step inside your own renderer, where you control the swapchain, writing it directly avoids the hooking question altogether.

ReShade against writing your own post-process pass

The real alternative for a developer is not another injector, it is doing the work in your own rendering code. If you own the renderer, a post-processing pass is a full-screen draw with your own pixel shader, and you already have the color target and, if you set it up, the depth buffer. You control the swapchain, the resource formats and the order of operations, and there is no DLL to load into someone else's process.

The difference in approach is where the shader language lives. ReShade FX is a C-like language with its own lexer, parser and preprocessor in this repository, and effects written in it are meant to run under ReShade's runtime rather than being compiled by your build. Writing your own pass means your shaders are in HLSL, GLSL or SPIR-V, compiled by your existing pipeline, with no preprocessor layer of ReShade's own. You lose portability of the effect across applications and you gain the ability to debug the whole path in one debugger.

ReShade's advantage is precisely the case where you do not own the renderer: a shipped game or a closed video application. There, the choice is between hooking and not having depth or color access at all. The standalone compiler is the middle ground for tooling authors, since the README states it can be integrated into other projects by adding the effect_* files.

Licence, maintenance and what an upgrade costs you

ReShade is licensed under the BSD 3-clause licence, and the README adds that some source files are dual-licensed and also available under the MIT licence when stated as such at the top of those files. For a project that links or vendors the code, that means the per-file header is the thing to check, not only LICENSE.md. BSD-3-Clause carries the usual attribution and no-endorsement conditions; if you redistribute a build, the notice requirements apply. This is a description of the licence text, not legal advice, and dual-licensed files need to be identified individually before you rely on MIT terms for any given file.

The repository is not archived, and the last push was on 2026-09-24. The README does not describe a versioning or deprecation policy for the ReShade API, and the repository has no published releases, so there is no published upgrade path to plan against from what the repository states. The practical upgrade cost sits in three places: the add-on API surface documented in REFERENCE.md, the ReShade FX language handled by effect_lexer.cpp and effect_parser_stmt.cpp, and the hook installation logic in hook_manager.cpp. An add-on that depends on a specific hook target is the most exposed, because it inherits both ReShade's changes and the host application's changes. Vendoring the standalone compiler is the least exposed, since the effect_* files are self-contained and the README presents them as usable on their own.

Editorial conclusion

Adopt ReShade if you are a Windows C++ developer who wants one runtime for ReShade FX effects across games and video software, or if you want to write an add-on against the ReShade API. Do not adopt it if your target is a platform the build instructions do not cover, or if you cannot accept a DLL hooking another application's rendering calls. Verify first that your Visual Studio version is 2017 or higher, that Python is on PATH for glad, and that your Git clone used --recurse-submodules, because the README's build steps assume all three.

Frequently asked questions

Official sources

1. crosire/reshade on GitHub
2. Issues
3. License: BSD-3-Clause
4. Project website
5. README