Providing game data to ReShade

Rendering before a shader means rendering into its SRV rather than its RTV. Looking further at things, I think I got your code wrong. It's always rendering before, just it's rendering into the RTV so very often an injected effect will just do nothing. I think I'll rewrite that then, and store a map of RTV->SRV pairs which are created and destroyed when needed. Further to that, a way to render directly after Draw might be ideal too. The API seems to have made assumptions about what people are doing with events, so before/after is not specifiable.

I will test that snippet you posted, thanks.

For credits, I used what is specified in the licence supplied by Shader Toggler. I can remove your real name but I want to get the licence as best I can without including a licence file in the archive itself. I guess I could add a button or dropdown to present the full licence within ReShade and leave in simplified credits elsewhere.

It's not possible to render into a SRV: A SRV is a view to a texture for shader binding. You can only render into RTVs (that's their purpose).
Any rendering a game does happens at draw calls ("addon_event::draw" and friends), everything else is just state updates and doesn't actually execute anything. The draw events are called before the actual draw the game requested is executed, but allow you to overwrite them, so you can always perform work both before (in the callback, returning false) and after (calling "cmd_list->draw()" with the passed in arguments in the callback, then doing the work and returning true), the API works both ways.

Sorry, I meant creating an RTV from the underlying texture and caching that.

Ahh the latter sounds like it should work perfectly, thanks.

Looks like getting views might be pushing the boundaries of what can be done that is renderer-agnostic within the API, since it ultimately returns opaque handles.

They aren't entirely opaque, those handles are well defined in most cases: For RTVs for example, in D3D11 it's a ID3D11RenderTargetView pointer, in D3D12 it's a D3D12_CPU_DESCRIPTOR_HANDLE to a RTV descriptor. The add-on API just makes it possible to create them without having to worry about which graphics API is actually being used, but if so inclined one can also get/create them through other means and simply pass those to the add-on API (by reinterpret casting to reshade::api::resource_view).

To be graphics API-agnostic it's preferable to rely more on the add-on API though, otherwise will have a bunch of `if (device->get_api() == ...) ... else ...` code paths, yeah ...

Recently with ENBseries it has been found that the Effects11 framework poorly manages device state which wastes a lot of CPU time and GPU calls. For ReShade shaders, is this at all an issue? i.e. are there optimisations so it's not iterating through all variables, textures, and potential DX11 calls every shader/frame, or do they save the calls to reuse them later? The potential of ReShade could be limited if there's performance issues related to accessing a lot of game data/variables/textures, when looking at scenarios/games with high performance requirements.

ReShade is using its own effect framework and runtime, that doesn't apply.

I just mean that for ReShade, how comparable is it to raw , single-threaded D3D11 calls in its performance impact.