Welcome, Guest.
Username: Password: Remember me

TOPIC: How does __RENDERER__ macro work?

How does __RENDERER__ macro work? 1 year 6 months ago #1

I know that SweetFX has a macro called __RENDERER__ that gives you the actual renderer that is being used. 0xD3D9 for D3D9, 0xD3D10 for D3D10, 0xD3D11 for D3D11 and 0x061 for OpenGL. I've been trying to make a shader but the value of this macro is not what I expected, and reading the changes of the 0.16 version of ReShade it seems that you guys changed the way it works, but i can't find any information about it. Can you guys tell me how it works now? I will really appreciate it. Thanks.
The administrator has disabled public write access.

How does __RENDERER__ macro work? 1 year 6 months ago #2

  • crosire
  • crosire's Avatar
  • Offline
  • Posts: 2540
  • Thank you received: 1455
Taken from the example shader (which I need to remember to upload somewhere again, it was part of the core download before, but that one no longer exists):

__RENDERER__
Renderer version in format 0x[Type][Major][Minor][Revision]. Examples:
  • 0x09300 is Direct3D9 SM3
  • 0x0A100 is Direct3D10.1
  • 0x0B000 is Direct3D11.0
  • 0x14300 is OpenGL 4.3
Cheers, crosire =)
The administrator has disabled public write access.
The following user(s) said Thank You: AlexPowerUp

How does __RENDERER__ macro work? 1 year 6 months ago #3

So if I want to detect if it's using OpenGL i just need to do this:
#if ((__RENDERER__ & 0x10000) == 0x10000)
  //opengl stuff here
#endif

I tried it and now it works. Thanks Crosire, your team is doing a good work.

By the way, the DPX shader of SweetFX makes some weird things on some OpenGL games like Doom 3. Instead of doing what it should do, it makes a blue filter and screws up all the screen. As far as I know the lerp fuction applied to the final color makes it to happen. Do you know any way to fix it?
The administrator has disabled public write access.

How does __RENDERER__ macro work? 1 year 6 months ago #4

  • crosire
  • crosire's Avatar
  • Offline
  • Posts: 2540
  • Thank you received: 1455
Correct. About the blue thing: Is that generally reproducable in OpenGL games (with the lowest amount of other options active as possible)? Are your drivers up-to-date (because of that red-blue-swap NVIDIA bug in old driver versions)?
Cheers, crosire =)
The administrator has disabled public write access.

How does __RENDERER__ macro work? 1 year 6 months ago #5

  • Martigen
  • Martigen's Avatar
  • Offline
  • Posts: 172
  • Thank you received: 40
crosire wrote:
Correct. About the blue thing: Is that generally reproducable in OpenGL games (with the lowest amount of other options active as possible)? Are your drivers up-to-date (because of that red-blue-swap NVIDIA bug in old driver versions)?
I can confirm the same problem with Wolfenstein: TNO, however that was back in maybe... version 14? Can't remember, and I don't currently have it installed to test with 1.0. When I free up some disk space (finish a couple of games!) I'll test it out. DPX was also the offending shader at the time, found through a process of elimination.
The administrator has disabled public write access.

How does __RENDERER__ macro work? 1 year 6 months ago #6

Martigen wrote:
crosire wrote:
Correct. About the blue thing: Is that generally reproducable in OpenGL games (with the lowest amount of other options active as possible)? Are your drivers up-to-date (because of that red-blue-swap NVIDIA bug in old driver versions)?
I can confirm the same problem with Wolfenstein: TNO, however that was back in maybe... version 14? Can't remember, and I don't currently have it installed to test with 1.0. When I free up some disk space (finish a couple of games!) I'll test it out. DPX was also the offending shader at the time, found through a process of elimination.
It still happens with ReShade 1.0 because it's the same shader. And it happens both in NVIDIA and AMD and in all architectures i tried out. As far as I know the shader begins doing some math with the original image and having them in a variable called "c0". When it mixes the original image with the "c0" variable, the blue shit happens in almost every OpenGL game. I guess that shader still needs mode development because there is a TODO statement. Is there an alternative for it that works in both D3D and OpenGL?
The administrator has disabled public write access.