# Renodx Architecture: A Deep Dive into the Modular DirectX Modding Framework > Explore the Renodx architecture: a modular DirectX modding framework featuring a CMake build system, a Reshade runtime engine, and game-specific add-ons for custom DLLs. - Repository: [Carlos Lopez/renodx](https://github.com/clshortfuse/renodx) - Tags: deep-dive - Published: 2026-09-06 --- **Renodx architecture consists of three distinct layers—a CMake-based build system that compiles and embeds shaders, a runtime engine that hooks into Reshade to manage DirectX resources, and a game-specific add-on layer that delivers compiled modifications as loadable DLLs.** The **clshortfuse/renodx** repository implements a sophisticated renovation engine for DirectX games built atop the Reshade framework. Understanding renodx architecture reveals how it intercepts rendering pipelines, upgrades swapchains to HDR, and replaces shaders without modifying original game files. ## Core Build System The foundation of renodx architecture resides in its CMake-based toolchain that transforms shader source code into embeddable C headers. The [`CMakeLists.txt`](https://github.com/clshortfuse/renodx/blob/main/CMakeLists.txt) orchestrates the entire process, beginning with the `build_shader_target()` function that discovers HLSL, SLANG, and GLSL files throughout the repository. This function invokes industry-standard compilers—**FXC**, **DXC**, **Slang**, or **glslang**—to generate bytecode, then passes the results to the `embed_file` executable located in [`src/embed_file.cpp`](https://github.com/clshortfuse/renodx/blob/main/src/embed_file.cpp). This tool converts binary shader blobs into C header files (`*.h`) that are directly included by add-on DLLs during compilation. Consequently, the final binaries ship with all shader resources internally embedded, eliminating external file dependencies. Each game-specific add-on is discovered via `file(GLOB ADDON_FILES …)` and compiled into a separate DLL named `renodx-.addon64` (or `.addon32`), linked against Microsoft Detours for function hooking and Reshade's public headers. ## Runtime Engine At execution time, renodx operates as a Reshade add-on, registering callbacks through the swapchain module hierarchy. The public façade in [`src/mods/swapchain.hpp`](https://github.com/clshortfuse/renodx/blob/main/src/mods/swapchain.hpp) delegates to version-specific implementations like [`src/mods/swapchain_v1.hpp`](https://github.com/clshortfuse/renodx/blob/main/src/mods/swapchain_v1.hpp), which contains the core runtime logic. ### Device and Swapchain Proxies The runtime creates optional proxy devices via `GetDeviceProxy` to enable HDR output, format upgrades, and fullscreen optimizations without altering the game's original device. When a swapchain is created, the engine intercepts the call through `OnCreateDevice` and may inject a proxy DirectX 11 or DirectX 12 device to host upgraded resources. ### Resource Cloning and Descriptor Management Central to renodx architecture is the `CloneResource` function, which duplicates textures and render targets with modified formats or usage flags. This enables HDR10 pipelines and custom render target workflows by creating cloned versions of back-buffers that the original engine continues to render into unaware. The descriptor management system uses `BoundDescriptorInfo` and `PushDescriptorInfo` structures to queue pending descriptor writes. The `FlushDescriptors` method commits these to the GPU only when necessary, minimizing overhead during frame rendering. ### Pipeline Layout and Proxy Shaders When upgrading a swapchain, the engine builds a minimal pipeline layout through `SetupSwapchainProxyLayout` on demand. It then utilizes full-screen proxy shaders—`swap_chain_proxy_vertex_shader` and `swap_chain_proxy_pixel_shader`—to draw the cloned back-buffer content. The `DrawSwapChainProxy` callback intercepts the final presentation phase, replacing the standard back-buffer with the upgraded clone while applying color-space transformations. Runtime state management attaches lightweight structs like `DeviceData` and `CommandListData` to Reshade objects using `renodx::utils::data::Create()`, ensuring thread-safe data access across asynchronous rendering commands. ## Add-on Layer The uppermost layer of renodx architecture consists of individual game modules residing under `src/games/`. Each module represents a self-contained modification compiled as a Reshade add-on DLL. Every add-on requires: - **[`addon.cpp`](https://github.com/clshortfuse/renodx/blob/main/addon.cpp)** – The entry point that registers Reshade event callbacks using `register_event`, including initialization hooks like `OnInitDevice` - **[`metadata.json`](https://github.com/clshortfuse/renodx/blob/main/metadata.json)** – A manifest describing supported architectures (x64/x86), required assets, and compatibility metadata - **Compiled shader headers** – Generated by the core build system and included via `#include "shaders.h"` The CMake configuration automatically packages each add-on with a runtime manifest generated by `generate-release-manifest.mjs`, creating distributable `.addon64` or `.addon32` binaries that Reshade loads at game launch. ## Cross-Component Data Flow The interaction between architectural layers follows a precise pipeline: 1. **CMake** discovers add-on sources and invokes `build_shader_target()` to compile shaders 2. **embed_file** converts bytecode to C headers embedded in the DLL 3. **Reshade** loads the add-on DLL at game startup, triggering `OnInitDevice` to create `DeviceData` instances 4. **Swapchain creation** activates `GetDeviceProxy` to allocate proxy devices for resource upgrading 5. **Rendering commands** are intercepted so that `ApplyRenderTargetClones` rewrites render-target views to use cloned resources 6. **Presentation** calls `DrawSwapChainProxy` to render the cloned back-buffer through full-screen shaders, applying HDR10 or custom tone mapping before display ## Summary - Renodx architecture separates concerns into **build system**, **runtime engine**, and **add-on layers**, enabling rapid game-specific mod development - The **CMake-based toolchain** compiles HLSL/SLANG/GLSL shaders and embeds them as C headers via `embed_file` to eliminate external dependencies - The **runtime engine** in [`src/mods/swapchain_v1.hpp`](https://github.com/clshortfuse/renodx/blob/main/src/mods/swapchain_v1.hpp) manages device proxies, resource cloning via `CloneResource`, and descriptor flushing through lightweight data structures - **Game-specific add-ons** compile as separate `renodx-.addon64` DLLs that hook into Reshade without modifying game executables - Architecture supports **HDR10 upgrades**, format conversion, and shader replacement through proxy swapchains and full-screen quad rendering ## Frequently Asked Questions ### How does renodx embed shaders into the final binary without external files? The build system invokes the `embed_file` executable defined in [`src/embed_file.cpp`](https://github.com/clshortfuse/renodx/blob/main/src/embed_file.cpp) to convert compiled shader bytecode into C header files containing byte arrays. These headers are included directly in [`addon.cpp`](https://github.com/clshortfuse/renodx/blob/main/addon.cpp) files during compilation, ensuring the resulting `renodx-*.addon64` DLL contains all shader resources internally. ### What is the purpose of resource cloning in renodx architecture? Resource cloning via `CloneResource` creates duplicate textures with modified formats or usage flags, allowing renodx to upgrade back-buffers to HDR10 or custom color spaces without the original game engine detecting the modification. The engine renders to the original resource while renodx presents the cloned, upgraded version. ### How do add-ons register with the Reshade runtime? Each [`addon.cpp`](https://github.com/clshortfuse/renodx/blob/main/addon.cpp) implementation calls Reshade's `register_event` function during initialization to subscribe to callbacks like `OnInitDevice`, `OnCreateDevice`, and `DrawSwapChainProxy`. This registration mechanism allows the runtime engine in [`src/mods/swapchain_v1.hpp`](https://github.com/clshortfuse/renodx/blob/main/src/mods/swapchain_v1.hpp) to intercept DirectX API calls and manage device lifecycles transparently. ### What distinguishes the swapchain_v1 implementation from the public swapchain interface? The [`src/mods/swapchain.hpp`](https://github.com/clshortfuse/renodx/blob/main/src/mods/swapchain.hpp) file acts as a façade that selects between implementation versions, while [`src/mods/swapchain_v1.hpp`](https://github.com/clshortfuse/renodx/blob/main/src/mods/swapchain_v1.hpp) contains the concrete logic for device proxying, descriptor management, and proxy shader execution. This abstraction allows renodx to evolve its swapchain handling without breaking existing add-ons that depend on the public interface.