Per-Game Customization (Internal value grabbing)

It's fairly obvious to anyone that Reshade as taken an "Anti-ENB" approach, in terms of customization per-game. Which works for a good color correction, lens correction and sharpening effect. However, depth buffer compatibility is iffy at best, and practically any other information is nonexistent entirely. This idea doesn't sacrifice Reshades cross-compatibility and would not require different binaries of Reshade to be created per game!

The idea is based off the principle of Reshade having built-in Texture2D values which are grabbed from memory (via memory address) that could be defined in-shader. A very rough example of what I'm talking about:
_{texture2D GBuffer { Width = BUFFER_WIDTH; Height = BUFFER_HEIGHT; Format = R16F; Address: 0x2E498B8; };}

The "0x2E498B8" part of course being fabricated randomly, could be used to point to an address in memory where the internal texture resides (In this example, the games G-Buffer). This would of course leave it up to shader programmers to get such information manually using tools such as RenderDoc. It would also require them to maintain multiple iterations of practically the same shader (and perhaps only support a select few games with commented out definitions for each, as well as requiring the maintenance of such through updates of the games.)

This could of course not be limited to textures, but also values such as position, rotation:
_{float3 PlayerPosition { Address: 0x7498BE8; };
float4 CameraRotation { Address: 0x4798BE1; };}

(Yes I only changed a few values in the example address, shutup.)

Its just an idea I've been pondering for awhile. And ultimately, would not task either the user with having to choose which binaries to use, or the shader programmers with being forced to even use the feature.

An argument against this feature would of course be that it would subsequently "divide" Reshades cross-game shader compatibility. A counterargument, however, might be that the Depth-Buffer's compatibility has much the same effect. Another argument could be hacking potential, which has and always will be a thing regardless if Reshade even existed. It's also not absurd to assume that if implemented, the VAST, VAST majority of shader programmers will not use, nor know how to use the feature. But I believe that the experienced minority that would, would give us delightful shaders with the freedom they've been given (A sort of unintentional quality control ).

Giving access to any memory is way to dangerous, not to mention hard to generalize. Applications use ASLR (address space layout randomization) these days, meaning there are no fixed addresses of objects anymore, they change every time you restart the game. Not to mention a heap of other tools that block unintentional memory access (which this would be). And don't get me started on how any of this would look like to anti-cheat tools.

It's a good idea, but just not feasible for the scope of ReShade.

Sorry to hear that. ENB desperately needs a competitor, I don't know if that will ever happen. I have intermediate knowledge of making trainers for games, maybe I could mess around with things such as DXWrapper; fork it perhaps. Hell, might even try to implement my idea into a Reshade fork Thanks for the quick reply!

Sorry to revive this topic, but it has come to my attention that a pre-existing solution has the ability to track textures through a hash identifier instead of a memory address. I have no experience, and don't know how it works, but here is a description of the functionality: github.com/bo3b/3Dmigoto/wiki/Replacing-textures
(It's also open-source, so we can figure out how it's done).

3Dmigoto is DX11 only, which leads to question whether or not this functionality is possible with DX9, OpenGL, etc. However, given the recent implementation of the new depth buffer detection (which is currently DX11 only officially), it likely wouldn't be too far fetched to implement something much like this, regardless if DX11 exclusive or not. 3Dmigoto also has the ability to scroll through all of the different textures in real-time to find the one you want (damn!)

It also has the ability to scroll through pixel and vertex shaders, mentioned here: github.com/bo3b/3Dmigoto/wiki/Switching-...d-for-shader-hunting

3Dmigoto's texture replacement functionality seems to be geared more towards world-space texture mods (trees, guns etc.) as apposed to render textures (g-buffer, normal buffer etc.), but I can't imagine the latter would be too different, in terms of a hashing method being the main form of tracking down the render textures.

Of course, this is how texture defining would look:
texture2D GBuffer { Width = BUFFER_WIDTH; Height = BUFFER_HEIGHT; Format = R16F; Hash = KSDK45JETYVDGN425; };

We can also look to a custom branch of Reshade which is specifically built for Guild Wars 2, and it's method of custom hooking: github.com/04348/Gw2Hook/blob/master/source/d3d9/hook_gw2.cpp

This might give some ideas, however, not only is this an older game, it also leads us back to the memory publication, which Crosire is opposed to. Since Reshade has already crossed the line of per-game configuration (depth buffer detection method), I don't see how this is that far off. I would love more input on this proposal, as it's the last one I got on this subject

EDIT: My other proposal, is that if Crosire is so worried about cheating, simply disable the functionality if network traffic is detected (like the depth buffer)