RenderDoc and Reshade

Hello All,

Had a quick question regarding the Hook order btw RenderDoc and Reshade. I am trying to verify that a texture is being bound properly when using the binding through reshade->bindresourceviews /reshade->push descriptors.
I noticed that even though I can sample the texture correctly in PS. Renderdoc says "No resource" bound in the draw call. 
This leads me to believe RenderDoc is hooked before reshade.

Also Had a couple more questions on Reshade/D3D API.
1. Does D3D intelliigently not make un-necessary uniform updates? Or does this have to be handled explicitly in Addon?. In OpenGL I did this manually. Also in D3D I saw that you can unbind a resource using PSSetResources(0, 1, {0}) - > I believe this should not affect PSSetShaderResources(20, 0, {0}) ? Because if I am caching on addon side this needs to be taken into account.

2. I believe if you use the start effect-runtime api. This is managed by reshade?

The addon is hooking into the API before "present" call. Similar to the "Generic DepthBuffer Addon". 

Thanks in advance. If anyone can confirm about RenderDoc. Also if you could provide a small explaination on "D3D" uniform variable. 

RenderDoc typically hooks before ReShade, so you won't see what ReShade is doing in its captures. There is a workaround implemented for the ReShade test application (if you build the "Debug App" solution configuration of ReShade), so that RenderDoc does capture ReShade in this test application, but it doesn't work with the normal ReShade in other games. As such it can be useful to do debugging in the test application, if possible (it doesn't do anything interesting though, apart from clearing the window to a fixed color and then applying ReShade).

1) You are typically working with constant buffers, rather than updating individual uniform variables in all but D3D9/old OpenGL, so that doesn't apply. But in general I wouldn't worry much about setting all state (resource view/sampler bindings etc.) again each time. You can unbind individual resources by binding null, yes.
If you need a helper that keeps track of state set by the application and to be able to restore that state after doing something, can take a look at this example which already does exactly that: github.com/crosire/reshade/blob/main/exa...e/state_tracking.hpp

2) If you mean what happens to state when calling "effect_runtime::render_effects", then you should not rely on ReShade restoring state to what it was before that call. It may be free to change state to whatever it needs, so that has to be handled by the add-on (see the aforementioned example on how to do so). In reality ReShade does currently restore state in D3D9-D3D11, to make things a bit easier, but that may change in the future and it's also not the case in D3D12/Vulkan already.

Thanks crosire for confirmation on the RenderDoc and detailed explainations to my questions.

1. Exactly what I was looking for w.r.t to state tracking
- App->BeginRender() (Don't know if there is a fool proof way to determine this trigger).
- App->RenderCode() (Reading some specific values from CBuffers, Resources here, also setting some samplers/textures as mentioned earlier)
- App->Present()
- Addon->RenderResources(For example SkyLUT, Scattering data)
- Reshade->orig->Present() (Graphics Out)

I tested this in Addon->RenderResources()(Right now only with a rtv->clear()). I didnt restore state. However the presentation was fine.

So I guess the state restore is done by Reshade?
Or DX automatically pick the BackBuffer from DirtyRects. Because I am changing RTV, Reshade must have restored it or "it just works". This is only for my info.

What I Ideally wanted to do was RenderOut Resources before App->BeginRender so that I can bind them in the App->RenderCode(). In the current path I can use the Resources only in next frame.

However I don't know if there is a foolproof way to correctly determine App->BeginRender.

"command_list::clear_render_target_view" itself doesn't change state in any way. The only add-on API calls that can change state are "command_list::bind_*" (obviously, since that is their purpose) and "effect_runtime::render_effects" or "effect_runtime::render_technique". So only need to worry about those.

Hello Crosire,

I am closing to completing my Addon. Couple of things I wanted to run by you.

First of all I would like to say that very nice work on Reshade API. I have not found any bugs at all. Thought I did couple of times turns out I had wrong init parameters etc .
Also No crashes. Restarted game several hundred times to build shaders mod game etc. 

1. I have written the addon code against the reshade build actually. Removed some parts/added some parts etc, The reason is that as I was new to DX12/DX11 API I was trying to figure out what I was doing wrong with resource creation etc. However now I am super comfortable with the API.

2. The addon code can be ported to a .addon file later quite easily. I haven't touched any reshade code. 

I would like to understand if there any limitations in distributing the DXGI.dll initially directly then switch to .addon later. which I want to do because then I would also have support of the host of post process reshade effects. I will attach the BSD3 licencse with the distribution.

 Possible due to reshade. 

1. Volumetric Fog.
2. Dynamic Sky atmosphere.
3. Some additional post processing help like more possible SSAO blur passes.

 

License-wise there is no issue (with ReShade itself, this does not apply to all the effect files, those are independently licensed). I would of course very much prefer add-ons to be distributed separately from ReShade. Just like presets should preferably not bundle ReShade. That ensures users will always get the latest ReShade version with all its goodies, along with the extra functionality from the add-on (can easily update to a newer ReShade version and continue using the same add-on build, as the API is backwards compatible). But I'm not going to be grudgy if you want to share your work with the world as soon as possible and clean it up to be a proper add-on a bit later

Totally agree to move the code to .addon. So that it can reuse reshade. The issue I am deep into the code now. Will take a day or 2 to test with .addon atleast. I still have pending work to replace a few object shaders. Will definitely maybe want to move faster to seperation.

I have used the ini_file from reshade to save custom Addon config. I think that should work just fine when moved to addon ?

Mod link for Darksouls2 :  www.nexusmods.com/darksouls2/mods/1146

Don't know how much you have played of it.

But here is also the reddit post
www.reddit.com/r/DarkSouls2/comments/13gumxh/ds2_lighting_mod/

Hello Crosire,

I need your advice on some issues. I am new to distribution

1. Some ppl are asking to mirror the package in their website typically the local ones like polish. Indicating they will not change the contents.

2. I think before 1.0 release I need to move this .addon mode. Because if 0.9 is like this and 1.0 is .addon. Ppl will get confused.

3. I have packaged the BSD license copy from github for reshade with the Mod. So Hope I did that the right way.