# RenoDX: a ReShade add-on that rewrites DirectX game shaders

> RenoDX is an HLSL toolset built on ReShade's add-on system that replaces shaders, injects buffers and upgrades swapchains in DirectX games. It is for people who want to change how a shipped game renders, not for people who want a plugin they can configure and forget.

**clshortfuse/renodx** — Renovation Engine for DirectX Games

- Repository: https://github.com/clshortfuse/renodx
- Website: https://renodx.com/
- Stars: 4,352 · Forks: 169
- Language: HLSL
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/clshortfuse-renodx

## What Renovation Engine for DirectX Games actually replaces

RenoDX is a toolset to mod games. The README lists its capabilities directly: it can replace shaders, inject buffers, add overlays, upgrade swapchains, upgrade texture resources, and write user settings to disk. That list is the scope. It is not a post-processing filter that sits on top of the final frame. Replacing a shader means the game's own HLSL is substituted at the point where the GPU would have compiled and run it, so the change happens inside the render pipeline rather than after it.

The audience follows from that. Anyone who has used a ReShade preset to add contrast or bloom is working one stage later in the pipeline than RenoDX does. RenoDX is aimed at people who want to alter what a shader computes, which in practice means people comfortable reading HLSL, following a game's render passes, and rebuilding a project. The repository's primary language is HLSL, which matches that audience. The README points contributors at CONTRIBUTING.md and, for the live devkit and MCP workflow, at DEVKIT_MCP.md, so a second audience exists alongside players: people writing new addons against the devkit.

## Why RenoDX rides on ReShade instead of patching executables

The README gives the reason for the architecture in one sentence: because RenoDX uses ReShade's add-on system, compatibility is expected to be pretty wide, and using ReShade simplifies all the hooks necessary to tap into DirectX without worrying about patching version-specific exe files. That is the central design decision. A tool that patches a game's executable has to be revised every time the game ships a new build, because the offsets and code it edits move. A ReShade add-on hooks the DirectX presentation path instead, so the same mechanism works across titles that share that path.

The trade-off is a dependency. RenoDX does not stand alone; it inherits ReShade's hooking behaviour and its constraints, and anything ReShade cannot attach to, RenoDX cannot reach either. The README's phrasing is "compatibility is expected to be pretty wide", which is a statement of expectation rather than a guarantee, and the project does not publish a compatibility matrix in the README. The practical answer to "does this work on my game" lives on the Mods wiki page, which the README links, rather than in the repository itself.

The mechanism also explains the tooling around the repository. A decompiler, decomp.exe, is published for Shader Model 6.0 and above. If you are going to replace a shader, you first need to see what it does, and a decompiler is the way in. That utility is listed alongside renodx-fpslimiter.addon64 and renodx-devkit.addon64, which suggests the project treats its own addons as a family of artifacts rather than a single binary.

## Installing RenoDX and running a first mod

The README does not contain install steps. It points to the Mods wiki page for mods and lists three downloadable utilities, so the honest starting point is that page rather than a command in the repository. What the repository does document is the build path for the project itself: CMakeLists.txt, CMakePresets.json, build.cmd and make-sln.cmd sit at the top level, with cmake/, external/, include/, src/, scripts/ and test/ alongside them. If you intend to build rather than download, those files are the entry points.

Building the project from a checkout starts with the provided batch scripts. The names are literal: build.cmd builds, make-sln.cmd generates a solution.

```bash
git clone https://github.com/clshortfuse/renodx
cd renodx
build.cmd
```

After the build completes, the outputs are addon binaries of the kind the README links for download, such as renodx-fpslimiter.addon64 and renodx-devkit.addon64. The README does not state where those binaries land in the tree, so check the build output rather than assuming a path.

For a Visual Studio workflow, the repository ships make-sln.cmd to generate the solution file, and CMakePresets.json to drive configuration.

```bash
make-sln.cmd
```

The README does not document the preset names inside CMakePresets.json, so open that file to see which configurations are defined before passing one on the command line. For a first real use, the sequence the project implies is: install ReShade, obtain or build the RenoDX addon, and then load the mod for your specific game from the Mods wiki page. The README does not describe that sequence step by step, and it does not document rollback, so keep a copy of any file you replace before you replace it.

## The devkit and MCP workflow is the part most users will not need

The README splits its contribution guidance in two: CONTRIBUTING.md for general work, and DEVKIT_MCP.md for the live devkit and MCP workflow. That second document is a signal about where the project's effort goes. A live devkit plus an MCP workflow is infrastructure for people iterating on shader replacements inside a running game, not for people consuming a finished mod. If you are in the first group, the devkit and the decompiler together are the actual product; the mods are the output.

If you are in the second group, this is the wrong layer to look at. Nothing in the README suggests a configuration file that a player edits to get a better image. The capability list is about replacing and injecting, and the utilities are a frame limiter, a devkit, and a decompiler. A player who wants a brightness adjustment is better served by the mod built on top of RenoDX for their particular game, which is why the Mods page is linked so prominently and the README itself is so short.

There is also a metadata layer. renodx-metadata-schema.json sits at the top level, and the capability list includes writing user settings to disk. A schema file in the repository root suggests settings are validated against a declared shape rather than parsed ad hoc. The README does not describe the schema's fields, so anyone writing settings by hand should read that file directly.

## Where RenoDX stops being the right tool

The clearest limitation is that RenoDX is not a general-purpose improvement. It replaces shaders and upgrades swapchains in DirectX games, and the README's compatibility claim is an expectation tied to ReShade's add-on system. A game that ReShade's add-on path cannot hook is out of reach, and no amount of HLSL work changes that. The README does not list such games, so the negative case is not enumerated anywhere in the repository.

The second limitation is that the project publishes continuously rather than in stable versions. The releases are a snapshot build plus dated nightlies, with nightly-20260923 and nightly-20260922 appearing one day apart. That cadence is useful if you are tracking a specific fix, and awkward if you want a version number to pin. There is no semantic version to reason about, so "which build am I on" becomes a date question.

The third is scope of documentation. The README is short by design. It defers mods to the wiki, contribution rules to CONTRIBUTING.md, and the devkit workflow to DEVKIT_MCP.md. It does not document rollback, does not document where build outputs are placed, and does not list the CMake presets. Anyone expecting the README to be a manual will be disappointed; anyone expecting it to be a signpost to the right document will not.

## RenoDX against a plain ReShade preset

The obvious alternative is ReShade on its own, and the difference is where in the pipeline the work happens. A ReShade preset applies effects after the game has finished rendering, reading the final colour buffer and writing a modified one. RenoDX uses ReShade's add-on system to reach earlier: replacing shaders, injecting buffers, upgrading swapchains and texture resources. The two are not competing for the same job. A preset can change the look of a finished frame; RenoDX changes what produced the frame.

That distinction has a cost. A preset is a text file you drop next to the game. RenoDX is a build system, an HLSL codebase, a devkit, and a decompiler, and it inherits ReShade as a hard dependency either way. If your goal can be met after the frame is composited, a preset is the smaller commitment by a wide margin. If the change has to happen inside the shader, no preset will get there, and RenoDX is the layer that can.

The project's own utilities show the same split. renodx-fpslimiter.addon64 is a frame limiter, which is a narrow, well-defined job. decomp.exe is a Shader Model 6.0+ decompiler, which only matters to someone reading shader bytecode. Both ship from the same repository because both serve the same workflow: understand the shader, then replace it.

## Maintenance, licence and what the release cadence costs you

The repository is not archived, and the last push was on 2026-09-23. The release list reflects that: a snapshot build dated 2026-09-22 and nightlies dated 2026-09-22 and 2026-09-23. Whatever else that implies, it means there is no long-term support branch to sit on. Upgrading means moving to a newer dated build, and the README does not describe a migration path between them, because there is no version boundary to migrate across.

The licence is MIT, stated in the repository metadata and present as a LICENSE file at the top level. MIT is permissive, which in practice means you can redistribute and modify the code provided you keep the licence notice. That is a statement about the project's own terms, not about the games it modifies. RenoDX replaces shaders inside commercial games, and game licences and anti-cheat policies are separate documents that the repository does not address. Check those yourself; nothing here is legal advice.

The maintenance cost you should budget for is the dependency, not the code. ReShade's add-on system is the hook, so a change there propagates to RenoDX, and the project's own cadence suggests it tracks upstream closely. If you are building addons, follow CONTRIBUTING.md and DEVKIT_MCP.md rather than inferring conventions from the tree. If you are consuming mods, the wiki is the surface that changes, and the repository is where the engine underneath it lives.

## Conclusion

RenoDX suits engineers and modders who are willing to read HLSL, build with CMake, and treat a game's render pipeline as something to be rewritten. It does not suit players who want a one-click HDR toggle, because the project ships a devkit and a decompiler rather than a universal patch. Before adopting it, check the Mods wiki page for whether your specific game has a mod, and confirm which release channel (snapshot or nightly) you intend to track, since both are published continuously.

## FAQ

### What is RenoDX used for?

RenoDX is a toolset to mod DirectX games. The README lists its capabilities as replacing shaders, injecting buffers, adding overlays, upgrading swapchains, upgrading texture resources, and writing user settings to disk.

### How much does RenoDX cost?

The repository is licensed under MIT, so there is no cost to use or redistribute the code under that licence. The README does not mention any paid tier or pricing.

### How do I install RenoDX?

The README does not contain install steps; it links a Mods wiki page and lists downloadable addon and utility files. Building from a checkout uses the top-level build.cmd and make-sln.cmd scripts, with CMakePresets.json defining the configurations.

### How do I use RenoDX HDR?

The README does not document HDR settings or an HDR workflow. It lists shader replacement, buffer injection, overlays, swapchain and texture upgrades, and writing user settings to disk, and directs mod-specific questions to the Mods wiki page.

### How do I install RenoDX?

The README gives no step-by-step install. It links the Mods wiki page for mods and lists renodx-fpslimiter.addon64, renodx-devkit.addon64 and decomp.exe as downloads; building from source uses build.cmd and make-sln.cmd at the repository root.

### How do I use RenoDX with Cyberpunk?

The README does not name individual games. It points to the Mods wiki page for available mods, and states that RenoDX uses ReShade's add-on system so compatibility is expected to be pretty wide.

## Sources

- [clshortfuse/renodx on GitHub](https://github.com/clshortfuse/renodx)
- [License: MIT](https://github.com/clshortfuse/renodx/blob/main/LICENSE)
- [Project website](https://renodx.com/)
- [README](https://github.com/clshortfuse/renodx/blob/main/README.md)
- [Releases](https://github.com/clshortfuse/renodx/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/clshortfuse-renodx