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)

@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.

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

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 :)

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

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!

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 :)

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.

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)

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)

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.

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

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...