A generic post-processing injector for games and video software.

Overview

ReShade

This is a generic post-processing injector for games and video software. It exposes an automated way to access both frame color and depth information and a custom shader language called ReShade FX to write effects like ambient occlusion, depth of field, color correction and more which work everywhere.

ReShade can optionally load add-ons, DLLs that make use of the ReShade API to extend functionality of both ReShade and/or the application ReShade is being applied to. To get started on how to write your own add-on, check out the API reference.

The ReShade FX shader compiler contained in this repository is standalone, so can be integrated into other projects as well. Simply add all source/effect_*.* files to your project and use it similar to the fxc example.

Building

You'll need Visual Studio 2017 or higher to build ReShade and Python for the gl3w dependency.

  1. Clone this repository including all Git submodules
  2. Open the Visual Studio solution
  3. Select either the 32-bit or 64-bit target platform and build the solution.
    This will build ReShade and all dependencies. To build the setup tool, first build the Release configuration for both 32-bit and 64-bit targets and only afterwards build the Release Setup configuration (does not matter which target is selected then).

A quick overview of what some of the source code files contain:

File Description
dll_log.cpp Simple file logger implementation
dll_main.cpp Main entry point (and optional test application)
dll_resources.cpp Access to DLL resource data (e.g. built-in shaders)
effect_lexer.cpp Lexical analyzer for C-like languages
effect_parser.cpp Parser for the ReShade FX shader language
effect_preprocessor.cpp C-like preprocessor implementation
hook.cpp Wrapper around MinHook which tracks associated function pointers
hook_manager.cpp Automatic hook installation based on DLL exports
input.cpp Keyboard and mouse input management and window message queue hooks
runtime.cpp Core ReShade runtime including effect and preset management
runtime_gui.cpp Overlay rendering and everything user interface related

Contributing

Any contributions to the project are welcomed, it's recommended to use GitHub pull requests.

Feedback and Support

See the ReShade Forum and Discord server for feedback and support.

License

All source code in this repository is licensed under a BSD 3-clause license.

Issues
  • Shortcut keys for switching backward or forward between presets

    Shortcut keys for switching backward or forward between presets

    Added shortcut keys for switching backward or forward between presets. They can be configured in the settings page jut below "Effect Toggle Key". Also the switching is no longer circular, It does not go directly from the last to the first preset anymore. For example: when using depth of field filter with manual focus and want to quickly go to the last preset (or the first), it will no longer go circular if pressing the shortcut key once more by accident. There aren't so many changes in code as the git is showing, because there was a re-indentation of a big block of c ode (which I think I could avoid it in fact, sorry for that)

    opened by antagonicus 26
  • cleared depth buffer detection rewritten for dx11

    cleared depth buffer detection rewritten for dx11

    @crosire: i rewrote the code related to the retrieval of the cleared depth buffer textures. The code is shorter and should be easier to adapt to dx10. The main improvement is the way the cleared depth textures are saved: now, when reshade makes a copy of the cleared depth texture, the destination texture is not initialized before each copy, but it is initialized only once (depending on the format and the dimensions of the source depth texture) . You will see too that this technique do not rely on the depth tracker: this is because, for a same depth stencil, there can be more than one depth texture. Also, there are cases where the good depth texture is not linked to the best match depthstencil.

    In the future, maybe we can have some more acurate statistics on the drawcalls and the number of vertices, so it will be possible to associate them to the depth textures.

    Also, with this new implementation, the selection of the depth texture format is not necessary anymore.

    opened by Thalixte 22
  • draw_call_tracker now tracks intermediate buffers (normals, motion vectors, etc) and constant buffers

    draw_call_tracker now tracks intermediate buffers (normals, motion vectors, etc) and constant buffers

    The primary goal of this pull request is to set the groundwork for capturing additional buffers useful for post processing shaders. In the future, Reshade could pass surface normals and/or camera transforms to the post processing shaders for things like ambient occlusion and temporal aliasing. A little more work needs to be done to this effect (heuristics and config options) - but this represents the back-end component

    • I wasn't able to test this on deferred context pipelines... but I don't think there should be any issues. It would be ideal if we could test that before merging into master
    • pointers to intermediate buffers that are drawn along side depth buffers are stored in a "snapshot"
    • pointers to constant buffers that are mapped along side depth buffers are stored
    • the draw_call_tracker::find_best_snapshot() function now (changed from draw_call_tracker::find_best_depthstencil() returns an object which contains rendertargets as well as the depthstencil
    • these additional buffers are not used anywhere yet
    • rather than keep track of rendertargets and depthstencils as they are drawn (with an _active_depthstencil variable) the rendertargets are queried during an on_draw. I don't think this causes any performance issues and it GREATLY enhances the ability of the draw_call_tracker to collect data
    • draw_call_tracker::verticies and draw_call_tracker::drawcalls are now total_verticies and total_drawcalls
    • the additional data about render targets and constant buffers should be displayed in the dx11 configuration/menu .... after we merge the new menu changes in and rebase this pull request, it will be easy to add those
    opened by el3ment 15
  • PoC: OpenVR support

    PoC: OpenVR support

    The VR community is in desparate need for a tool like Reshade to improve blurry visuals or poor color utilisation on LCD displays. So I thought I'd give it a shot to see how hard it would be to integrate support for VR titles into Reshade :) This is the minimal set of changes I could come up with to apply a Reshade effects toolchain to D3D11 games using OpenVR.

    I do not expect this PR to be merged as-is, there is definitely some work to be done before it could be deemed production-ready. I rather wanted to start a discussion with you early and get your feedback, specifically if you are even interested in VR support to begin with :)

    There is an interesting architectural challenge with this, as OpenVR support is not actually a new, separate runtime, but rather an extension to the existing graphics runtimes. In particular, it replaces the on_present event for a window's backbuffer with eye texture submissions. Unfortunately, the runtimes are currently fairly tightly coupled with the concept of a window, backbuffer and input. For this first proof of concept, I hacked into the D3D11 runtime and provided it with an alternative constructor/on_init function that does not require a swapchain and instead creates a simple texture as a backbuffer. This allows me to reuse the effect chain application without too much work. A more sophisticated solution might require to decouple the effect chain from the runtime to make it reusable on its own, but I'm not familiar enough with the code to provide a good proposal for this.

    As it stands, my current approach will make games create two runtimes, one managing the window's backbuffer, and one managing the OpenVR pipeline. The first one is useful for configuring Reshade via its UI, but it does waste some frametime during normal gameplay. The VR runtime skips some features like UI and input support and only applies the effect chain to the eye textures. One drawback currently is that the two runtimes are not synchronized; if you use the Reshade UI to edit the effect chain, you'll have to restart the game before it is applied to the VR runtime.

    Aside from that, I've successfully tested and used it with a few games, most notably Skyrim VR and Fallout 4 VR. Other D3D11 games may work, but I've also seen some crash or produce garbage output. So there's definitely some need for further debugging :)

    Other needed improvements:

    • support for other graphics APIs besides D3D11
    • depth texture support (if games even submit it to the OpenVR compositor, which not many games appear to do)
    • better error handling
    • possibly code style adjustments

    I'll happily continue to work on this, if you want me to, to get it into a state you'd be comfortable merging. If not, that's also fine; it was a fun experiment either way. Thanks for this amazing tool :)

    opened by fholger 10
  • UWP compatibility

    UWP compatibility

    This is an attempt to make Reshade works with UWP games. I need your help to make it work (if it is possible).

    I managed to make the GUI appear in Forza Horizon 4, as well as make the basic shaders work (those that do not need depth buffer access)...

    here is a log: https://pastebin.com/pbcgh42C

    FH4 Forza Horizon 4

    Forza Horizon 4 good depth buffer

    opened by Thalixte 10
  • Better depth buffer detection / drawcall tracking for D3D11

    Better depth buffer detection / drawcall tracking for D3D11

    This PR contains a better depth buffer detection system and drawcall tracking. It is designed to work with normal immediate-context focused engines and also for multi-threaded / deferred engines and engines using compute shader stream rendering. The code is implemented for Direct3D 11 as the main problem with the current implementation is around multi-threaded usage of deferred contexts, something that's not implemented in Dx10 or earlier.

    It uses device context based tracking to avoid locks / bottlenecks in the runtime and uses just 1 lock around commandlist - tracker pairs which is minor and doesn't impact any drawcalls in the highly multithreaded engine of e.g. Assassin's Creed Origins. It now also tracks calls made to DrawAuto, DrawIndexedInstancedIndirect and DrawIndexedIndirect, something the current build lacks (and adding them makes engines using these methods run into a serious bottleneck in the runtime).

    The depth buffer detection uses heuristics for screensize/depth buffer size matching so it also matches a depth buffer when resolution scaling/supersampling is used where the depth buffer is larger or smaller than the window/screen.

    Performance seems to be a little higher than in the current 3.1 release too (but not that much, a couple of fps). I also fixed the drawcall / vertices display in statistics, which always ended up being 0.

    As I'm not a seasoned C++ developer (I've spent the past 15 years writing C# ;)) I hope I've done everything right, but feel free to comment on the code so I can correct it.

    One thing that's likely going to bug you is the SDK version which is bumped up as I used VC++2017 15.5. Hopefully that's something you can live with.

    Let me know if you have remarks or change requests!

    opened by FransBouma 10
  • Two fixes: mouse cursor change on splitter bar and node expansion bug on techniques list

    Two fixes: mouse cursor change on splitter bar and node expansion bug on techniques list

    Two changes/fixes:

    • When the mouse is now hovered/above the splitter bar, the mouse cursor is changed to the vertical resize cursor. This makes it easier to see when the splitterbar is active. I tried several things to make it better, but it appears the techniques tree has a padding below it of several pixels, which is unavoidable it seems. This makes it look as if the splitter bar starts right below the horizontal bottom border of the techniques tree, but that's not the case. This small change makes it easier: the user can now see where the splitter bar is and makes moving the splitter bar easier

    • Fix for an issue where a technique was moved due to reordering with the mouse: If a technique was reordered in the list in such a way that the filename (e.g. Dof.fx) appeared twice or more times in the tree, the nodes all got the same ID. This had the effect that only the first node with the filename 'Dof.fx' was expandable in the top pane with the techniques: all other nodes with 'Dof.fx' were not expandable. This change fixes that by assigning a unique ID to the treenodes containing the filename.

    The ordering goes wrong in some occasions with drag/drop, likely due to some issue inside imgui. perhaps it's a good idea to add a separate tab with only the order of the techniques, so it's separated from the technique tree itself as it's a separated concern. But that's for another day :)

    opened by FransBouma 7
  • Fix the special uniform

    Fix the special uniform "mousepoint" returning invalid coordinates

    Currently, if the mouse leaves the display in multi-display configurations while the hooked application window is active, out of bounds/invalid mouse coordinates will be returned. Feel free to ignore this one if it's intended for shader developers to take advantage of that functionality.

    opened by Mortalitas 6
  • Fixed hook queuing flag

    Fixed hook queuing flag

    hook::apply_queued_actions() was getting called immediately for queue_enable == true (probably not important, but it does cause every thread in the process to be suspended every time a single hook is installed)

    opened by LukeRoss00 6
  • Add cache for effect

    Add cache for effect

    This pull request has following changes:

    • Cache preprocessed effect files. (It is about the "Generated HLSL".)
    • Cache compiled effects.

    Total time of loading 161 effects in my PC: (preprocess & parse time) + (compile time) = (Total time until display splash screen) First load (no cache): 12.3 sec + 20.7 sec = 33.0 sec ~Second load (cached): 6.8 sec + 3.1 sec = 9.9 sec~ Second load (cached): 2.5 sec + 2.7 sec = 5.2 sec (https://github.com/crosire/reshade/pull/154/commits/3b66b11e9a6668a4c1138b86f22ba01f89fd61b8)

    opened by ghost 6
  • Select the preset from directory iterator

    Select the preset from directory iterator

    This request changes the behavior of the preset list.

    • GENERAL::PresetFiles will not be used.
    • Change the value of GENERAL::CurrentPreset from index of GENERAL::PresetFiles to path of current preset.
    opened by ghost 6
  • Added Windows Multimedia Module (winmm.dll) hook

    Added Windows Multimedia Module (winmm.dll) hook

    Added Windows Multimedia Module (winmm.dll) hook to allow to launch reshade for games that are difficult to hook early to catch the rendering api. For example HL Alyx in VR etc. I choose to add this hook as the winmm.dll ist often the most early dll loaded by the game/application which helps to get the hook in the game at the right time. Had a few issues for VR titles and this helps to have universal hook. Still it might cause a bit more cpu cycles due to additional hooks that are actually only needed to load reshade and not to really to intercept the methods.

    I imported all methods from the winmm.dll interface and partly generated the exports and the basic method cages. The rest was done by hand using the original interfaces. Not sure if that was required to automatically pass all dlls calls to the original dll or if there was an easier way on how to do it. Let me know if that is ok how it is implemented or if you would like to have it differently

    opened by retroluxfilm 2
  • Track depth textures for VR

    Track depth textures for VR

    This took a while, but I now have depth support working on a range of Unity and Unreal VR games, and Skyrim.

    Disclaimer: many effects using depth are probably too expensive for VR, anyway, and are also prone to shimmering artefacts due to slight mismatches in calculation between the two eyes. Therefore, this feature is probably not as useful for VR as for flat games. So not supporting depth for VR games in favour of a simpler VR integration is definitely an option :)

    Anyway, here is a rough rundown of what I had to do to get depth working:

    Getting color and depth texture dimensions to match

    The majority of games I encountered seem to be using a single big texture for both eyes during submit, and consequently their depth texture is the same. So far, Reshade has copied the submitted region for each eye and processed them separately, then copied the region back. To get a matching depth texture during post-processing, this would require to also do a regional copy of the depth texture. Unfortunately, D3D11's CopySubResourceRegion does not support that for depth/stencil textures, and so you'd have to use a (compute) shader for the copy. I did originally plan to add a copy_resource_region function to the command_list interface, but I found no clean way to implement a compute shader call within d3d11::device_context_impl.

    Instead, I now always give the full color texture to the runtime, so that the original depth texture will match. If the game sends the same texture for both eyes with different regions, I only call the runtime for the first submit, so that we don't process both eyes twice in a frame. It's a bit less elegant, but appears to also be ever so slightly faster for games that use the single big texture approach.

    (This also invalidates my statistics hack in the other PR, but that's probably a good thing :D )

    Communicating with the depth plugin

    To properly track the depth textures for VR, the depth addon needs a few extra pieces of information from the runtime. For a starter, it needs to even recognize that it's dealing with a VR runtime, and it also needs the current eye and the submitted region to differentiate between the possible depth setups in a VR renderer. I added a small struct with a set_data call on the runtime that the depth addon can retrieve.

    Tracking the depth textures

    Given that there can be up to two separate depth textures, the state in the state_tracking_context (selected texture, view, potential backup) needed to be replicated for the VR eyes. So I extracted them into their own struct. I also added a timestamp of the last drawcall to the counters so that we can decide which depth texture belongs to which eye (if separate textures are used). Most games probably render the left eye first, so that's the default assumption, but I also added a config option to swap the eyes if necessary.

    Dealing with the options for depth setup in VR

    I've encountered a couple of different ways that depth textures may be used in VR games, and this is the way I deal with them:

    • single big texture for color and depth containing both eyes: this one is straight-forward, as it works pretty much the same as for flat games. Just find the best match for the color texture resolution and provide that. The majority of Unity and Unreal games as well as Skyrim/FO4 use this approach.
    • single small texture reused for both eyes: in this case, you have to make an (extra) copy of the depth texture on clear for the first eye. When the game finds only a single matching depth texture, it will automatically set this one up to be copied on clear. If needed, there's also an extra config option to force the clear index for this first eye. I've encountered this setup in 'Elven Assassin', and with this approach depth is working.
    • separate small textures for each eye: this is where the timestamp of the last drawcall comes into play to assign the textures to each eye. Aside from that, it's straight-forward.
    • separate small textures for color, single big depth texture: 'Talos Principle' does that, and I assume other Croteam games (Serious Sam) probably do this as well. I assume they also have a single big color buffer somewhere, but they submit individual color textures for each eyes. Therefore, the depth texture will not match the color texture size, and without implementing a region copy for depth textures, this case is not solvable and hence not supported in this PR...
    opened by fholger 7
Lee Thomason 290 Jun 9, 2022
SatDump - A generic satellite data processing software.

SatDump A generic satellite data processing software. Thanks Mnux for the icon! Still WIP Usage First of all, as with any program using volk, running

Altillimity 234 Jun 24, 2022
A collection of post-processing shaders written for ReShade.

ReShade FX shaders This repository aims to collect post-processing shaders written in the ReShade FX shader language. Installation Download this repos

null 729 Jun 26, 2022
Violent Fungus is a command and control (C2) software suite, providing red teams post-exploitation persistence and other juicy stuff.

Violent Fungus is a command and control (C2) software suite, providing red teams post-exploitation persistence and other juicy stuff.

Chris Humphries 31 May 31, 2022
Cobalt Strike is a commercial, full-featured, remote access tool that bills itself as "adversary simulation software designed to execute targeted attacks and emulate the post-exploitation actions of advanced threat actors".

COBALT STRIKE 4.4 Cobalt Strike is a commercial, full-featured, remote access tool that bills itself as "adversary simulation software designed to exe

Trewis [work] Scotch 81 Jun 19, 2022
Vireo is a lightweight and versatile video processing library written in C++11

Overview Vireo is a lightweight and versatile video processing library that powers our video transcoding service, deep learning recognition systems an

Twitter 851 Jun 20, 2022
Free,Open-Source,Cross-platform agent and Post-exploiton tool written in Golang and C++, the architecture and usage like Cobalt Strike

Khepri Free,Open-Source,Cross-platform agent and Post-exploiton tool written in Golang and C++ Description Khepri is a Cross-platform agent, the archi

Young 1.3k Jun 24, 2022
A demo of the relevant blog post: Hook Heaps and Live Free

LockdExeDemo A demo of the relevant blog post: Hook Heaps and Live Free DEMO Explanation There are 2 compile types. The first is an EXE. The EXE requi

null 141 Jun 22, 2022
null 3 Jan 19, 2022
Jaws is an invisible programming language! Inject invisible code into other languages and files! Created for security research -- see blog post

Jaws is an invisible interpreted programming language that was created for antivirus research. Since Jaws code is composed entirely of whitespace char

C.J. May 206 Jun 19, 2022
Tactile-Arcade-Games - Wrote a C program comprised of four separate games that run in a loop using the PSoC 5LP board and Cypress IDE.

Tactile-Arcade-Games - Wrote a C program comprised of four separate games that run in a loop using the PSoC 5LP board and Cypress IDE. Used two potentiometers, two ADCs to convert their voltages to digital values, a PWM to drive two servos, an 8x8 RGB LED matrix, 40 digital output pins and 8 power MOSFETS to control the matrix, and a character LCD display.

null 2 Dec 24, 2021
A library to develop kernel level Windows payloads for post HVCI era

A library to develop kernel level Windows payloads for post HVCI era

Dmytro Oleksiuk 244 Jun 26, 2022
Blog post on using a custom Bash builtin to parse INI config files

Writing a Bash Builtin in C to Parse INI Configs Why Not Just Parse INI Configs With Bash? Shell languages such as Bash excel at certain tasks, such a

Jesse Hathaway 14 Apr 6, 2022
code for the Proxy DLL example blog post

ProxyDLLExample A simple DLL for Windows that can be used to demonstrate a DLL Proxy Attack. This project uses GCC through MinGW was tested on Ubuntu

Cobalt Strike 42 Apr 22, 2022
Defold Engine integration with Yandex.Metrica to track your games on Yandex.Games.

Yandex.Metrica for Defold Yandex.Metrica is a free of charge web analytics tool for websites, that's the reason why we can use it for HTML5 games. Yan

Indiesoft LLC 6 Jan 20, 2022
Edited and relatively up-to-date xenos injector

Xenos Windows dll injector. Based on Blackbone library - https://github.com/DarthTon/Blackbone Changes from the original repository Up-to-date blackbo

null 5 Apr 18, 2022
A USB-PD sniffer/injector/sink based on Google's Twinkie, re-designed to be manufactured by mere mortals.

Twonkie - a USB-PD sniffer based on Google's Twinkie Twonkie is a USB-PD sniffer/injector/sink based on a Google project called Twinkie, re-engineered

Joachim Fenkes 93 Jun 22, 2022
A USB-PD sniffer/injector/sink based on Google's Twinkie, re-designed to be manufactured by mere mortals.

Twonkie - a USB-PD sniffer based on Google's Twinkie Twonkie is a USB-PD sniffer/injector/sink based on a Google project called Twinkie, re-engineered

Joachim Fenkes 93 Jun 22, 2022
PoC MSVC COFF Object file loader/injector.

COFFInjector A Proof of Concept code - loading and injecting MSVC object file. Blog post with explanation: https://0xpat.github.io/Malware_development

null 119 Jun 13, 2022