How does __RENDERER__ macro work?

  • Posts: 3
4 years 6 months ago #1 by AlexPowerUp
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.

Please Log in or Create an account to join the conversation.

  • Posts: 3634
4 years 6 months ago #2 by crosire
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
The following user(s) said Thank You: AlexPowerUp

Please Log in or Create an account to join the conversation.

  • Posts: 3
4 years 6 months ago #3 by AlexPowerUp
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?

Please Log in or Create an account to join the conversation.

  • Posts: 3634
4 years 6 months ago #4 by crosire
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)?

Please Log in or Create an account to join the conversation.

  • Posts: 429
4 years 6 months ago #5 by Martigen

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.

Please Log in or Create an account to join the conversation.

  • Posts: 3
4 years 6 months ago #6 by AlexPowerUp

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?

Please Log in or Create an account to join the conversation.