![]() |
ReShade
A generic post-processing injector for games and video software.
|
The ReShade API lets you interact with the resources and rendering commands of applications ReShade was loaded into. It abstracts away differences between the various graphics API ReShade supports (Direct3D 9/10/11/12, OpenGL and Vulkan), to make it possible to write add-ons that work across a wide range of applications, regardless of the graphics API they use.
A ReShade add-on is a DLL that uses the header-only ReShade API to register callbacks for events and do work in those callbacks after they were invoked by ReShade. There are no further requirements, no functions need to be exported and no libraries need to be linked against. Simply add the include directory from the ReShade repository to your DLL project and include the reshade.hpp
header to get started.
Optionally an add-on may export an AddonInit
function (with the function signature extern "C" bool AddonInit(HMODULE addon_module, HMODULE reshade_module)
) if more complicated one-time initialization than possible in DllMain
is required, which will be called by ReShade right after loading the add-on module. Similarily it may also export an AddonUninit
function (with the function signature extern "C" void AddonUninit(HMODULE addon_module, HMODULE reshade_module)
) that will be called right before unloading (but only if initialization was successfull).
Here is a very basic code example of an add-on that registers a callback that gets executed every time a new frame is presented to the screen:
After building an add-on DLL, change its file extension from .dll
to .addon
and put it into the same directory as ReShade. It will be picked up and loaded automatically on the next launch of the application.
For more complex examples, see the examples directory in the repository.
It is also supported to add an overlay, which can e.g. be used to display debug information or interact with the user in-application. Overlays are created with the use of the docking branch of Dear ImGui version 1.86. Including reshade.hpp
after imgui.h
will automatically overwrite all Dear ImGui functions to use the instance created and managed by ReShade. This means all you have to do is include these two headers and use Dear ImGui as usual (without having to build its source code files):
Do not call ImGui::Begin
and ImGui::End
in the callback to create the overlay window itself, ReShade already does this for you before and after calling the callback function. You can however call ImGui::Begin
and ImGui::End
with a different title to open additional popup windows (this is not recommended though, since those are difficult to navigate in VR).
Overlay names are shared across ReShade and all add-ons, which means you can register with a name already used by ReShade or another add-on to append widgets to their overlay. For example, reshade::register_overlay("Settings", ...)
allows you to add widgets to the settings page in ReShade and reshade::register_overlay("OSD", ...)
allows you to add additional information to the always visible on-screen display (clock, FPS, frametime) ReShade provides.
The graphics API abstraction is modeled after the Direct3D 12 and Vulkan APIs, so much of the terminology used should be familiar to developers that have used those before.
Detailed inline documentation for all classes and methods can be found inside the headers (see reshade_api_device.hpp
for the abstraction object classes and reshade_events.hpp
for a list of available events).
The base object everything else is created from is a reshade::api::device
. This represents a logical rendering device that is typically mapped to a physical GPU (but may also be mapped to multiple GPUs). ReShade will call the reshade::addon_event::init_device
event after the application created a device, which can e.g. be used to do some initialization work that only has to happen once. The reshade::addon_event::destroy_device
event is called before this device is destroyed again, which can be used to perform clean up work.
To execute rendering commands, an application has to record them into a reshade::api::command_list
and then submit to a reshade::api::command_queue
. In some graphics APIs there is only a single implicit command list and queue, but modern ones like Direct3D 12 and Vulkan allow the creation of multiple for more efficient multi-threaded rendering. ReShade will call the reshade::addon_event::init_command_list
and reshade::addon_event::init_command_queue
events after any such object was created by the application (including the implicit ones for older graphics APIs). Similarily, reshade::addon_event::destroy_command_list
and reshade::addon_event::destroy_command_queue
are called upon their destruction.
ReShade will also pass the current command list object to every command event, like reshade::addon_event::draw
, reshade::addon_event::dispatch
and so on, which can be used to add additional commands to that command list or replace those of the application.
Showing results on the screen is done through a reshade::api::swapchain
object. This is a collection of back buffers that the application can render into, which will eventually be presented to the screen. There may be multiple swap chains, if for example the application is rendering to multiple windows, or to a screen and a VR headset. ReShade again will call the reshade::addon_event::init_swapchain
event after such an object was created by the application (and reshade::addon_event::destroy_swapchain
on destruction). In addition ReShade will call the reshade::addon_event::create_swapchain
event before a swap chain is created, so an add-on may modify its description before that happens. For example, to force the resolution to a specific value, one can do the following:
ReShade associates an independent post-processing effect runtime with most swap chains. This is the runtime one usually controls via the ReShade overlay, but it can also be controlled programatically via the ReShade API using methods of the reshade::api::effect_runtime
object.
In contrast to the described basic API abstraction objects, any buffers, textures, pipelines, etc. are referenced via handles. These are either created by the application and passed to events (like reshade::addon_event::init_resource
, reshade::addon_event::init_pipeline
, ...) or can be created through the reshade::api::device
object of the ReShade API (via reshade::api::device::create_resource()
, reshade::api::device::create_pipeline()
, ...).
Buffers and textures are referenced via reshade::api::resource
handles. Depth-stencil, render target, shader resource or unordered access views to such resources are referenced via reshade::api::resource_view
handles. Sampler state objects are referenced via reshade::api::sampler
handles, (partial) pipeline state objects via reshade::api::pipeline
handles and so on.