3.0 alpha feedback

Here's some limited 3.0 beta feedback.

- Please don't write an ini file in the game's folder. This is a particular problem with games installed in program files, as on Windows 10, apps aren't really allowed to write in Program files. Best way to do this I think is simply write the file in Documents\My Games\Reshade\<game name>\

Tried The Witcher 3 (1.12.1). (x64)

- Shift-F2 doesn't do anything, so reshade doesn't appear. I installed reshade manually (renamed Reshade64.dll to d3d11.dll as GoG installs dxgi.dll into the game folder with an overlay which has to be there otherwise the game crashes). I tried windowed and full screen, no change.
- Log here: pastebin.com/RH4y11xB

Tried Assassin's Creed Syndicate (latest version). (x64)

- The setup tool thinks it's an OpenGL game (it's D3D11 ) so I had to manually copy the reshade dll to the game folder (64bit) and renamed it to dxgi.dll
- Once in-game, shift-F2 again doesn't work, but the game renderer doesn't either. I did saw for one frame or so, the reshade startup text at the beginning. The game simply renders a full screen with one color which changes every frame or so. In-menu it works fine. Verified that Reshade 2.0.3f works fine.
- Log here: pastebin.com/YMgTnzAM

Tried Crysis 3 (32bit)

- success, at least the header for Reshade 3.0 shows up, shift-F2 works, the in-game UI shows up.
- Switched to dev mode
- Mouse input is still going through to the game engine (game in full screen) if the mouse is over the dialogs, so had to open in-game console to make it work.
- shader discovery isn't recursive it seems, I have to specify the folder where the fx files are located. It would be nice if this is recursive, but you probably already knew that
- Of course the found fx files I have are for 2.0 and all fail to work as parts of them are in cfg files which are skipped and they rely on Reshade.fx which is no longer there so I couldn't get any of my shaders to work, which wasn't unexpected: I think I have to move the #defines in the cfg file to the fx files, I also rely on some things defined on a common.fx file, and I have no idea whether that has to be included in each fx file or that includes might work (and thus namespaces).

A thing about the uniform vars
one of my shaders uses a uniform to cache a set value. This is a variable used by the shader and isn't for editing. I think there might be more shaders doing this, so it's probably a good idea to either:

• mark all uniforms which have to be edited in some way (like ENB does): so no control specification, no editor
• mark a uniform which shouldn't be edited with an accessor keyword, like 'private': private uniform bool _blah < source ... . << not edited. Of course you remove that 'private' keyword in your own parser.

It also might be a good idea to have the doc comments which are now in the .cfg files to show up as a tooltip. I see the imgui lib supports tooltips, so it might be good to have that text be present in the uniform definition with the control (again same as ENB does), so if it's specified, and the user hovers the mouse over the control the tooltip shows up (after a delay when the mouse isn't moved). Or that the help text is shown elsewhere. Not sure if this is already done, as said I couldn't get a shader to work due to the format being v2.0 format.

If you could give some small list of things to do wrt the existing shaders, I could look into porting at least mine and also others, if time permits.

Hope this helps. If I need to test debug builds, just let me know, I have VS.NET installed in that machine so could debug if you want.

First of all, thanks a lot for the comprehensive feedback!

The INI in the game folder is created only to have a default preset to save changes to. But it's for testing only and that behavior isn't going to be in the final build.
The actual configuration can be found in %appdata%\ReShade.

The setup tool just searches the executable for a DLL import ReShade can work with. So if it selects OpenGL, that doesn't mean the game is actually rendering with OpenGL, but it is at least loading it, which is enough for ReShade to work.

I find it strange that mouse input goes through in Crysis 3, because that's one of the games I checked it with (only in the main menu though). I'll have to check again, could be that I accidentally commented out some code for the build.

Shader discovery is not recursive by design. That would drastically slow down ReShade if the user enters a search path with many subdirectories.

You'll have to rename Common.fx to Common.fxh or similar, so it is not picked up as a separate effect and can be safely included. You probably have to copy some definitions from ReShade.fx into your effect as well (I.e. ReShade::BackBuffer and/or the depth linearization code). For now you can simply include the old cfg file directly. The undef file you can get rid of.

Initially ReShade only showed uniform variables with a "ui_type" annotation. I removed that restriction for now to make it easier. The definition of the "uniform" keyword defines it to be always "public" anyway. I also don't see why you would need to use a uniform variable to cache a value. They cannot be changed from a shader anyway, so better use an explicit constant variable (by making it "static const" instead of "uniform"). Those won't show up in ReShade and it's even possible for the compiler to optimize them away.

I second the idea to allow some kind of help text on uniforms. Easiest way would be to use another annotation. Comments are stripped away by ReShade's lexer/tokenizer and are not available to the parser, so I cannot use those.

crosire wrote: First of all, thanks a lot for the comprehensive feedback!
The INI in the game folder is created only to have a default preset to save changes to. But it's for testing only and that behavior isn't going to be in the final build.
The actual configuration can be found in %appdata%\ReShade.

Ah cool. Keep in mind that %appdata% is a hidden folder by default and thus users won't be able to see it by default. Whether that's a problem is of course up for debate. personally I wouldn't care (my software also stores its config there) but unless reshade has some sort of export feature for presets, sharing them by copying files from that hidden folder is perhaps going to be a problem for some people

I find it strange that mouse input goes through in Crysis 3, because that's one of the games I checked it with (only in the main menu though). I'll have to check again, could be that I accidentally commented out some code for the build.

Same here: in the menu of the game it works fine, in-game it doesn't. My guess is they use WM_ message based mouse input in the menu and Direct input in-game.

Shader discovery is not recursive by design. That would drastically slow down ReShade if the user enters a search path with many subdirectories.

It might not be that slow, but I guess it's not a problem once the shaders are ported, as they'll likely be in just 1 folder, so no need to specify all these sub folders...

You'll have to rename Common.fx to Common.fxh or similar, so it is not picked up as a separate effect and can be safely included. You probably have to copy some definitions from ReShade.fx into your effect as well (I.e. ReShade::BackBuffer and/or the depth linearization code). For now you can simply include the old cfg file directly. The undef file you can get rid of.

Ah, thanks for the info

Initially ReShade only showed uniform variables with a "ui_type" annotation. I removed that restriction for now to make it easier. The definition of the "uniform" keyword defines it to be always "public" anyway. I also don't see why you would need to use a uniform variable to cache a value. They cannot be changed from a shader anyway, so better use an explicit constant variable (by making it "static const" instead of "uniform"). Those won't show up in ReShade and it's even possible for the compiler to optimize them away.

In my case I use it to remember a color, picked by the mouse, so when the mouse overlay is enabled, the color below the mouse coord is used, when the mouse overlay is disabled, the color picked last is kept (in the uniform). this of course isn't needed anymore with a proper in-game editor. However it would still be great to have the option, as it might be other usages of uniforms which are not to be edited might occur (E.g. timer based CoC in a DoF, something which is present in ENB dof's and which to my knowledge needs a uniform to keep track of how long the timer has run). Not a much used feature, I'm sure, but if it could be build in now without much effort, it would make things more flexible and future proof.

I second the idea to allow some kind of help text on uniforms. Easiest way would be to use another annotation. Comments are stripped away by ReShade's lexer/tokenizer and are not available to the parser, so I cannot use those.

Agreed, something like this?
Any idea regarding the 64bit problems btw?

Presets aren't stored in the AppData location. They can be loaded from any arbitary location (paths are resolved relative to the game folder by default). Either way, I added another option for loading settings from as specified in the other topic now.

Yep, "ui_tooltip" sounds good.

As for the compatibility issues. I cleaned out a lot of code, might have broken some things in the process. I can check against The Witcher 3 in a few days. I'll also look into Crysis 3 again (this time not only in the main menu).

Fixed the bug where input went through when it shouldn't in games using raw input or DirectInput (which uses raw input behind the scenes these days), i.e. Crysis 3.

First many thanks for the release of 3.0 alpha, so I've finally tried 3.0:
(very) positive things:
* 3.0 consists of just a few files
* very easy setup / installation
* neat-looking + fast-responsive & highly customizable ingame UI
* no delayment after alt-tabbing out & back into the game

problems I encounter:
* the game Soma: Reshade ingame UI text is visible, but the text under section -Home- is invisible,
when I hover the mouse over it, info pops up, but I cant change the settings there
* same with game Juarez 2 Bound In Blood: invisible text under section -Home-
* I had to pause the game, otherwise the ReShade ingame UI mouse pointer was locked (not really a problem)
* I cant find the (for example SweetFX) cfg files, only in dir. C:\Users\User\AppData\Roaming\ReShade I found some ini files
* Is there a way to manually edit the cfg files (for example the SweetFX settings)

Is this the latest version?:
reshade.me/forum/general-discussion-2/19...ssion?start=60#14908
www.mediafire.com/download/upx1578a1h8f0tp/ReShade+3.0.0a1.7z

ReShade 3.0 does not come with shaders. Those are separate. You can use the SweetFX files for testing, or one of the Framework versions. Either way, 3.0 presets use uniform variables. None of the available shaders make use of those yet.

crosire wrote: ReShade 3.0 does not come with shaders. Those are separate. You can use the SweetFX files for testing, or one of the Framework versions. Either way, 3.0 presets use uniform variables. None of the available shaders make use of those yet.

I used previous ReShade framework in combi with 3.0 Alpha as well, but still no visible area beneath section -Home- in ingame UI.
I will try your new Alpha #3 #4 today, thank you for the regular updates.

I've tried a few things with Alpha #3 #4:
* I've stacked ReShade.fx + ReShade folder (from ReShade 1.1) & ReShade1.fx (renamed) + bayer16x16.png (from Marty's MXAO)
--> area beneath section -Home- in ReShade ingame UI: only post-process ReShade1.fx was visible & editable

* Same as above only used Reshade 2.0 instead of 1.1
--> same result only post-process ReShade1.fx was visible

With other words I cant use the previous ReShade framework packs in combi with 3.0 as you wrote for testing.

Activate developer mode and look at the error log. Compilation failed.

crosire wrote: Activate developer mode and look at the error log. Compilation failed.

d3d9.log

In all the games i tested, using the new ReShade alpha completely kills mouse input in the game.

Please make us able to switch between DirectX versions, automatic detection isn't always choosing the right version.

I have to say that when the overlay is up, the fact that the game still gets mouse events is extremely frustrating.

ScureHD wrote: Please make us able to switch between DirectX versions, automatic detection isn't always choosing the right version.

Rename dll acordingly? I personally never use the setup, I check what fx version and if 32 or 64 bit, extract the ReShade32 or 64.dll and rename it accordingly.

dustymonkey wrote: I have to say that when the overlay is up, the fact that the game still gets mouse events is extremely frustrating.

Which game? Shouldn't be the case with alpha #5.

ReShade32.dll
File Version - 3.0.0.42 - 6/7/2016 4:00PM

Skyrim - Game still gets mouse events when overlay is up but mouse is off the overlay.
Half-Life 2 - Mouse input is extremely laggy (over 1s delay) when overlay is up _and mouse is on the overlay_ but game does not appear to get off-overlay mouse events.
Portal 2 - Same as Half-Life 2.

Kerbal Space Program (32-bit executable, Unity 3D) Mouse lag on the overlay is 5+ seconds (seriously.)

This game uses faux fullscreen (game set to 1280x720, all the textures are desktop resolution of 1920x1080)

dustymonkey wrote: Skyrim - Game still gets mouse events when overlay is up but mouse is off the overlay.

This is intended behavior.

dustymonkey wrote: Half-Life 2 - Mouse input is extremely laggy (over 1s delay) when overlay is up _and mouse is on the overlay_ but game does not appear to get off-overlay mouse events.

Thanks for the example game. Managed to fix the input lag.

crosire wrote:

dustymonkey wrote: Skyrim - Game still gets mouse events when overlay is up but mouse is off the overlay.

This is intended behavior.

Then I will repeat my comment:

I have to say that when the overlay is up, the fact that the game still gets mouse events is extremely frustrating.