Renodx Architecture: A Deep Dive into the Modular DirectX Modding Framework

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 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. 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-<name>.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 delegates to version-specific implementations like 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<T>(), 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 – The entry point that registers Reshade event callbacks using register_event, including initialization hooks like OnInitDevice
• 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 manages device proxies, resource cloning via CloneResource, and descriptor flushing through lightweight data structures
• Game-specific add-ons compile as separate renodx-<name>.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 to convert compiled shader bytecode into C header files containing byte arrays. These headers are included directly in 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 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 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 file acts as a façade that selects between implementation versions, while 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.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}