A Question for Coders Familiar with ReShade's HLSL

I'm trying to figure out what exactly these texture2D coding's are. Here is an example:

and

This seems to be unique to ReShade. What would be the PURE HLSL implementation of these?? I'm trying to port things over to a system that doesn't have code like that.

Thanks.

ReShade shaders are written in the ReShade FX language, which is very similar to HLSL, but has a few additional features. See github.com/crosire/reshade-shaders/blob/master/REFERENCE.md for reference.

This particular feature is not possible with HLSL alone. It's a unique feature to ReShade which allows to define textures in shader code that does exist in neither HLSL, nor GLSL. In those you can only reference textures that were created in application code.

Crapola! So, the only alternative then for HLSL would be to actually create a texture? So I would have to use this:

...????

So what actually goes on with ReShade's implementation of this unique feature? "BUFFER_WIDTH" is equivalent to "Screen Width", right? So, how could I create a texture that would satisfy what ReShade does in these instances and port it directly to HLSL? Using the post above, I would need a texture that is (for a 1440p display) 2560x1440, has an alpha channel, and five mipmap levels? Am I misunderstanding? What would be an effective way to translate that native ReShade stuff into HLSL?

Thanks for your help, crosire!

The "< X = Y >" syntax is unique to ReShade FX too. HLSL has annotations of the form "< TYPE X = Y >", but they don't do anything if not implemented by the application. So no, this is no alternative, it won't work in plain HLSL too.

You simply cannot create a texture in HLSL code. You can only do that in the client-side application code (which would be written in C++ or similar).

crosire comes baring bad news.

So, just out of curiosity, what is actually happening behind the scene with ReShade when that sytax is called?

And a "thank you" is more than deserved in this case.

One should note that your syntax tries to load a static texture from any file. Textures in shadercode are different, they can change over time. Basically all you can see onscreen in a game is the current state of the COLOR texture - which changes frame by frame. A screenshot is basically just a dump to disk of the current state of the color texture at the point where you pressed the screenshot key. If you load a texture from a file, ReShade creates a texture in memory very similiar to the color texture that holds what is onscreen atm but fills it with the static color information from the texture you specified.
creates a texture a pass can read from and more importantly, write to. It's empty by default and a pass needs to fill it with data. Almost all the time this data is derived from the screen texture in any way so it's dynamic over time.
creates a texture with the static data from the noise.png specified. You cannot write to such a texture with a pass. Oblivion Reloaded supports such a thing, so you can load your own external textures.

However as crosire said, you cannot create a texture like the first one in Oblivion Reloaded.

Ah. Understanding what is happening is good. Thank you, Marty! So basically, I have to take it up with the author of Oblivion Reloaded. Now that I better understand what is going on, I will ask him what it would take to implement something like that.

I'm thinking my next question is going to be dense in nature and annoying, but WTH...
Is there a way to "loophole" the writable texture feature that ReShade implements? For the record, I'm assuming the answer is "no" and that you all have said so 3 times now, but...

No .
Oblivion Reloaded needs to support custom render targets for that and set up the target texture as writable.

Alrighty. I will take this to the OR developer then.

Thanks all.