ReShade: Implement Custom ReShade DLL Name

[sonic2kk]

Mostly resolves #873, as the core issue there is that ReShade is selecting the wrong DLL. There was an issue raised with the UX of enabling ReShade, but that is not resolved in this PR. It will be tackled separately.

Background

Currently, STL will copy over the ReShade DLL for the relevant game architecture (such as ReShade32/64 for 32bit and 64bit respectively). It copies the same DLL but names it dxgi.dll and d3d9.dll. Only one of these will ever be read by a game, but using this DLL covers us for Direct3D 9 (d3d9.dll) and Direct3D 10/11/12 games (dxgi.dll). However, there can be cases when this is problematic, such as in #873 where a game will crash if it tries to read d3d9.dll.

A proposed solution for that is to only copy one DLL, defaulting to dxgi.dll, and allowing the user to select/enter their own name for the ReShade DLL. This is useful for cases like that mentioned in the above issue, and also allows for avoiding conflicts where a modloader may already be using the ReShade DLL name. A custom name could avoid conflicts.

Implementation

This PR implements a combobox entry textbox for selecting a ReShade DLL name, or entering a custom one. This name is then used for the 32bit/64bit ReShade DLLs in the game folder. Users can by default choose dxgi.dll, d3d9.dll, d3d11.dll, and opengl32.dll. They can also enter a custom name. The textbox also allows for inputting comma-separated DLL names, so they can optionally copy over multiple DLLs if they so choose: for example, dxgi.dll,d3d9.dll (which will mimic existing behaviour).

When the ReShade DLL name is blank, we default to dxgi.dll.

On Windows, ReShade will default to dxgi.dll, and tell the user they have to check which DLL is right for whichever API the game is using. PCGamingWiki has a helpful list: https://www.pcgamingwiki.com/wiki/ReShade#Compatibility_list - We should document this on our wiki, too.

This PR also implements support for using ReShade with OpenGL games, as it now allows the user to copy the OpenGL DLL and will also automatically set the OpenGL DLL override, allowing games to work. This was tested with "DOOM 3: BFG Edition". Some other games (such as Hotline Miami running under Proton with the -gl option) could be tested.

Testing

The following games have been tested up to the point of showing the ReShade menu:

• NieR:Automata (Direct3D 11)
• DOOM 3: BFG (OpenGL)
• Let's zig zag (Direct3D 11)
• Sonic Mania (Direct3D 9)

Existing ReShade installs have not been tested, and I have not actually tested any shaders. In general, this PR would benefit from testing by those who actively use ReShade

Compatibility/Remaining Issues

There are a couple of concerns I have with compatibility which have not yet been resolved. I also do not have a clear idea on how to handle these cases just yet either:

• When changing the selected ReShade DLL, the previous ReShade DLL remains. If a bad DLL name is chosen (such as using d3d11.dll on a game that doesn't like it, such as Let's zig zag), then the game will be left in a bad state and the user will have to remove the DLL themselves. This would also apply on Windows.
  • Automatically trying to manage removing this DLL could be tricky, due to DLL naming conflicts
• There has been no testing with existing ReShade installs. If we go with the above to remove DLLs, this could be a problem, as d3d9 and dxgi will exist in the game folder, but the game may be using d3d9. Since dxgi is the default, if a user does nothing, updates, and just starts playing, ReShade may stop working. Likewise, if a modloader has since started using a DLL and has overridden one of the ReShade DLLs, this could get removed.

For the two above reasons, I think the best solution is to simply ignore bad ReShade DLLs. Even with existing behaviour, if a bad DLL was chosen, the user would have to manually remove it. Since now we only copy one DLL and let the user choose the name, it may be okay to expect them to choose the name sensibly and to manage ReShade+mods together, to know not to inadvertently overwrite a DLL.

There is also a case where a DLL we're trying to move into the game folder already exists. In these cases it was proposed to have a dropdown, with the preferred behaviour being to rename the DLLs, but I am a bit torn on this. For simplicity I would like to leave it up to the user to manage how they name their DLLs and resolve conflicts, but I am also curious as to what ReShade does on Windows. If ReShade overwrites, then we should too.

Documentation

We should update the ReShade wiki once this is merged to note some of the changes here:

• Mention how naming the DLLs works and which API the DLL names line up with (such as dxgi being for Direct3D 10/11, etc) - This is covered in the tooltip on the UI, but I would also like to explicitly call it out
• Mention that if no value is passed, dxgi is the default (also mentioned on tooltip)
• Mention that comma-separated options are supported (also mentioned on tooltip)
• Point to PCGamingWiki ReShade Compatibility List which documents ReShade support and which DLLs/APIs to use for a game (https://www.pcgamingwiki.com/wiki/ReShade#Compatibility_list)
• Point out that DLL name conflicts can occur and that they should be managed by the user (unless we choose a different approach, but I think the responsibility is on the user to tinker responsibly)
• More?

---

TODO:

• Test with existing installs
• Test duplicate DLL names (if opengl32.dll already exists and we try to name a ReShade DLL opengl32.dll when that was not placed by us (missing from ReShade.txt in game folder), existing opengl32.dll should become opengl32.dll.bak).
• Test some shaders (ideally someone more familiar with ReShade than me should do this)
• Test if this actually resolves the problem in ReShade bugs with DirectX version detection #873 (it should, probably)
• Add .dll extension to filenames without extension
• Update wiki to include documentation
  • Notes for existing installs (default name is now dxgi.dll, which may conflict with any existing DLLs i.e. mod DLLs)
  • Notes that DLLs can be renamed now (useful for avoiding conflicts with modding DLLs)
  • Notes that multiple DLL names can be passed, so it is possible to simulate the old behaviour
  • Notes that OpenGL games work now
  • Notes that Vulkan games do not work in general for ReShade on Linux, and that vkBasalt is recommended for such instances
  • Notes that renaming a DLL will not remove the previously placed one, so it will have to be removed manually (important if a DLL name is chosen that does not work, the DLL will need to be renamed manually)
• Update langfiles
• Version bump (In case I forget)

[sonic2kk]

Following discussion in #873, we'll probably just go with backing up any existing DLLs with the same name that we're trying to use by default if this is a first-time ReShade install. Any further changes to this behaviour can be adjusted based on user feedback. Since the user can choose any name now, this makes sense imo in case they accidentally overwrite a DLL.

As for when we change the name of a DLL and still have a stray one, I think this is fine. It might make the internal files a bit messy but the user can clean it up if they really care about that (they'd probably have to do this with mods and such anyway too - when tinkering, expect to get your hands dirty!)

So the main things left to do with this PR are:

• Update the tooltip to note about DLLs getting overwritten
• Update the wiki to note all the new functionality and caveats
• Note somewhere on the changelog and wiki that existing installations may need to set a new ReShade DLL name, and that the default name is now dxgi.dll (in case any mods are using this)
• Back up DLLs we're potentially overwriting but only for new ReShade installs (i.e. no ReShade.txt in the game directory).

---

I want to get these changes in soon, as this is useful imo and also fixes OpenGL with ReShade which is a cool win.

[sonic2kk]

Pushed a change to try to detect when a DLL with the same name as our chosen name exists in the game folder, but is NOT present in ReShade.txt. In this case we can assume STL didn't install this DLL. The performance cost of this could vary if the file ever got really big, but it would need to be a lot of lines, and a user probably won't populate this file with that many names. For times when they do, we can document this on the wiki.

This change is for now untested.

[sonic2kk]

Added dxgi.dll,d3d9.dll to the new dropdown on the Game Menu. This allows users to more easily simulate existing behaviour, which will be a little handy for migrating if users want to keep both DLLs.

[sonic2kk]

For some reason, it looks like the dropdown always defaults to dxgi.dll... I thought I fixed this before. I will investigate.

[sonic2kk]

D'oh, I used the wrong arguments for cleanDropDown. Just needed to swap the order to have the actual config file value be the first argument. Will be fixed in the next push.

[sonic2kk]

6fbe8e5 adds a check for DLLs to ensure they end with .dll if no extension is given. I did this instead of checking specifically for the .dll extension in case users want any kind of specific DLL name for some reason. But if no extension is given we can assume this is wrong I think.

There is also some logic to ensure these updated names are written to the game config file. For example if the user writes out dxgi.dll,d3d9, when we try to install ReShade we will update the internal array that tracks these names to use d3d9.dll instead. Then after we install ReShade, we write this array back out to the config file. That way if the user writes out dxgi.dll,d3d9 or even just dxgi, STL will catch this when we're installing ReShade and the config file will be updated to use dxgi.dll.

That commit also fixed the silly issue with choosing the wrong DLL name.

[sonic2kk]

There seem to be cases where the DLL names in the game config can sometimes get duplicated. For example, openg32.dll can become opengl32.dll,opengl32.dll, but I am not sure why this happens and it has only happened a couple of times during testing. The code in my local is intelligent enough to discard this (have not pushed changes yet).

I noticed some issues with how we were handling the .bak logic so I updated that which turned into a big refactor of installRSdll. Still testing but things look promising!

[sonic2kk]

Pushed a commit that refactors installRSdll. We check if the DLL we want to create already exists on the game folder path, and if it is already tracked by us (if ReShade.txt exists && if the DLL name is NOT in the ReShade.txt file). If all of these conditions are true, then we assume a conflict and rename the existing DLL to existing_name.dll.bak.

If the DLL already exists on the path and if it IS in the ReShade.txt file, then we assume it's an existing file we're already tracking and ignore it.

This should NOT impact ReShade Update because that's in a separate block, and if RESHADEUPDATE is enabled, we first check the DLL version. If (the versions don't match OR there is no ReShade version information on the dll) AND (if the ReShade DLL name has a conflict (file exists, file is not in ReShade.txt), then we assume a DLL conflict and back up the old file. Otherwise, the file is tracked by us already as a ReShade DLL, and we update is accordingly.

The installRSdll function was also refactored to be a bit more straightforward to read (save for the nested ifs, which can be a bit tricky, especially with Bash) and to remove the NOD3D9 argument since it isn't used anymore.

---

So as well as testing for DLL conflicts, I also tested the DLL naming changes I made. If the DLL doesn't end with a file extenion, I tested a few cases to ensure that the .dll extension would be appended.

---

Basically all that's left for this is testing actual shaders, and then updating the documentation+langfiles.

[sonic2kk]

I wonder if it's worth doing any kind of notifier work for this... Unsure for now.

It's probably too noisy, so this could always be added later if we really want.

[sonic2kk]

A nice QoL enhancement might be to check for duplicate ReShade DLL names, like if the user actually enters opengl32.dll,opengl32.dll. It might be nice to trim off any duplicates.

It would be possible to do this with something like printf "%s\n" "${RSDLLNAMEARR[@]} | sort -u", but then the order of the items entered would get re-arranged. Not sure if I really like that, and writing a loop to exclude duplicates would be a bit slow and a bit overkill just for this, especially when the code can already handle duplicate DLLs.

[zany130]

lgtm tested, and everything works as expected for the most part. Just some minor things.

1. Selecting say dxgi.dll first and then switching to opengl.dll install reshade into dxgi.dll and then also opengl.dll. ( a user may try one API and then realize it doesn't work and pick a different one) so in this case dxgi.dll should be "uninstalled" i.e reverted to its original non reshade state (if it existed)
2. In the same scenario as above, the ReShade.txt file contains the following

d3dcompiler_47.dll
dxgi.dllopengl32.dll

notice the lack of line break between dxgi.dll and opengl32.dll

3. Maybe we should write to ReShade.txt on every launch with the values of RESHADEDLLNAME ( and obviously add d3dcompiler_47.dll)
4. minor but selecting update seems to always reinstall the reshade .dll. maybe a checksum can be checked or something?

[sonic2kk]

Thanks a bunch for testing! Some great observations here that I'll try to address. With some luck this should be ready for the weekend 🥳

---

Selecting say dxgi.dll first and then switching to opengl.dll install reshade into dxgi.dll and then also opengl.dll. ( a user may try one API and then realize it doesn't work and pick a different one) so in this case dxgi.dll should be "uninstalled" i.e reverted to its original non reshade state (if it existed)

Tackling this may be tricky. I chose to let this case be on the basis that a user should be responsible for which DLL name they choose. Going into the game files and removing the offending DLL is the approach I chose to go with.

I am not sure how we could know when we should remove the DLL, in other words how we can tell that a DLL is definitely a previously added ReShade DLL. I think there may be some kind of strings check we can do, but we'd have to do this on every single DLL, which would be costly in terms of performance.

A possible fix would be to store and compare the previous ReShade DLL name or names, but there could be a case like this:

1. User installs ReShade with selected DLL name d3d11.dll
2. User then installs a mod which uses d3d11.dll (i.e. HMM modloaders)
3. User realises this is is going to conflict with ReShade, and so renames the ReShade DLL in the STL Game Menu to dxgi.dll (as an example)
4. If we implement the logic of trying to remove a DLL with the old name, this would remove the modloader, since the previous name the user chose for the ReShade DLL matches the modloader DLL

I fear being too "hands-on" with removing DLLs from the game folder could end up being problematic. Even renaming them could have the same effect: A user still has to go and intervene in the game files. I would rather leave the unnecessary DLLs in place.

The case you've brought up is absolutely valid and even something I encountered but I don't know a good way to deal with it. Warning the user on the wiki about this and documenting how to resolve this kind of issue (i.e. game crash, Direct3D error messages) may be the way to go, essentially to say "tinker responsibly" 😉 It is annoying but to my understanding it is possible to have this happen on Windows if the user chose an invalid rendering API name (such as if they chose D3D11 and it started causing a game to crash).

I recognise though that for STL we use the DLL names and not the API names, and as you pointed out in #873 it may not be immediately clear to the user which DLL to choose. I'm hoping the tooltip which explains it (albeit a little verbosely) will help alleviate this, and we'll also document this on the wiki, so hopefully users will be able to find out which DLL name to choose for the corresponding API. And if they don't know the API they'd have to look it up on Windows, too.

As an aside, I went with the DLL names over the API names for simplicity (mapping the names would've been a bit of a pain...) and since the user can enter DLL names, I think it makes slightly more sense to just take DLL names. I did consider as well having the option to enter both the API name and DLL names, and perhaps trying to map multiple values (i.e. accepting DX9, D3D9, Direct3D 9, DirectX 9, etc) but I realised this could conflict with the custom DLL names (i.e. if the user for some reason wanted Direct3D9.dll as the DLL name). Essentially I went with a more hands-off approach here, leaving it up to the user, though I did add a couple of safety guards like ensuring the DLL always has an extension and defaulting to .dll if no extension is provided.

---

Maybe we should write to ReShade.txt on every launch with the values of RESHADEDLLNAME ( and obviously add d3dcompiler_47.dll)

Absolutely. I came to a similar conclusion below but wrote it all out before I actually saw this point. Great idea, I will add this. It might have a slight performance cost, especially if the user is adding a lot of ReShade DLLs. This is extremely unlikely imo, I'd say maybe a handful of DLLs at most is the most likely scenario. It should be feasible to do and will ensure the contents of ReShade.txt only contains d3dcompiler_47.dll and whatever DLLs the user has selected.

Justification for Writing to ReShade.txt every launch

I wrote this before reading the above point but I'm keeping it in this reply mostly so I can refer to it and remind myself as well of what needs to be done and why 😅

There is a different problem though. This d3d11.dll in this scenario is still tracked by SteamTinkerLaunch as a ReShade DLL. If we keep going with the modloader example, let's say a user ends up with general modding conflicts between, say, a lighting mod and ReShade, and they then disable ReShade, STL uses ReShade.txt to determine which DLLs to set to "off", and this would include d3d11.dll since it was previously tracked as a ReShade DLL (it was the original name the user chose) but now it is a mod DLL.

To fix this, we'll need to re-create the ReShade.txt to have only the relevant tracked ReShade DLLs, in other words we need to make sure the only DLLs tracked in ReShade.txt are d3dcompiler_47.dll and the ReShade DLLs selected/entered by the user in the DLL name box.

I'll implement this tonight if I have some time.

---

In the same scenario as above, the ReShade.txt file contains the following [...]

Wow! That is a really good catch. This is a bug and potentially a fairly significant one actually (almost definitely exclusive to this PR though), there should be a newline. This should hopefully be fixed as part of better managing which DLLs are listed in the ReShade.txt file.

minor but selecting update seems to always reinstall the reshade .dll. maybe a checksum can be checked or something?

Interesting, the code is supposed to check the ReShade version from the given ReShade DLL. It would be interesting if you could check the log in a scenario when an up-to-date ReShade DLL is present but still gets overwritten. I remember you mentioning this in your OP for #873, but I thought it was fixed as I didn't notice it during testing for this PR. I will also take another look though later tonight.

[sonic2kk]

So it turns out removing and writing out to the ReShade.txt on each boot is a bit trickier than I thought. Since we rely on this file to tell what the tracked ReShade DLLs are, we couldn't do it before the DLL installation. So I decided to test out removing and re-writing to the file after we move the DLLs. Essentially once we move the DLLs we update the ReShade.txt at the end instead of in installRSdll. I think this makes sense, essentially "committing" a write of our tracked ReShade DLLs and removing any that we no longer select. I am still testing, but it is looking good for now.

[sonic2kk]

Okay, that approach seems to be working well. Basically:

1. User does a fresh ReShade install with dxgi.dll as the default. This is moved into the game files and is written to ReShade.txt
2. ReShade isn't working, user realises this is a mistake, and decides to rename the DLL to opengl32.dll
3. The opengl32.dll is moved to the game files, and the ReShade.txt is updated to only include d3d47 and their newly selected DLL name - The previous dxgi.dll is removed from ReShade.txt, however it remains in the game files since we can't reliably know if or when it should be removed
4. User installs some mod that uses dxgi.dll as the modloader DLL, which overwrites the still-existing but untracked ReShade dxgi.dll
5. User installs some mods, then realises "uh oh, I spent 50,000 hours modding this game and lighting no longer works, what should I do?!" - They identify ReShade as a possible culprit and disable ReShade
6. STL will mark all tracked DLLs in ReShade.txt to be suffixed with .dll_off - Since the ReShade.txt no longer includes the now-overwritten dxgi.dll, it will be left out and ONLY the DLLs entered for the ReShade DLL name box (and d3d47) will be suffixed with .dll_off.

So now as of the latest commit, we will only track ReShade DLLs that are entered into the ReShade DLL name box, and d3d47, so that the above scenario worked. If not for that, any superfluous DLLs that the user had ever previously entered, would be marked with .dll_off, even if they did that a long time ago by mistake. Now, we only track the entered ReShade DLL names, which is logical imo.

This was a great catch on your part, it was a little tricky for me to think through how to resolve it without breaking the checks for existing DLLs, but I think this works. Please let me know if you find any fault in this logic, because in my head I still have a nagging feeling that this may not be solid so a Second Opinion would help put my mind at ease a little :-)

You've helped out a lot with the ReShade stuff and I'm really grateful you're always willing to help test out. But I wanted to say that I'm not going to come back and point the finger at you if you don't catch a certain edge-case. If there's a flaw with the logic that you missed or anything else in this PR that's fine, I'm just looking for a bit of testing to give me a bit more confidence that this actually works, from someone who is a bit more experienced with using ReShade than myself.

If there are problems discovered later on you can always open an issue, and otherwise I am sure someone will complain about it eventually :-)

---

I could not reproduce the issue of the ReShade.txt missing a newline between the DLL names. Did you by any chance use a space instead of a comma for example? I believe it's mentioned in the tooltip but before this is merged this will be documented on the wiki as well, in case this is just a usage-related issue. Unfortunately it is not really possible to check for commas and spaces though (DLL names could contain commas, but it is unlikely, though imo it is slightly more likely they could contain a space even if I also think that's just asking for trouble).

We write out to the ReShade.txt file using a redirected echo, basically echo "$1" >> "$INSTDESTDIR/$RSTXT" - where $1 is the DLL name and the part after the >> is the path to the file to redirect to. echo will add a newline automatically, so a newline should get appended, unless the DLL name is being set incorrectly somewhere.

---

I will investigate the ReShade updating issue you mentioned, as well as doing some (hopefully) minor code refactoring, then I think this PR should be good to merge now that the ReShade DLL tracking issue is resolved. I believe that is the last outstanding piece of work assuming the updating DLLs works as expected, i.e. only updating when the ReShade DLL version does not match our selected version. There may be a conflict in when we check for updates here with the new ReShade conflict logic in this PR, so I will be looking around that area of the code first as a potential culprit.

This is still looking on track to be merged soon, assuming I have not made any silly mistakes with resolving conflicts+writing out our tracked DLLs to the ReShade.txt appropriately.

[sonic2kk]

I was testing the ReShade update and it seems to be working for me. It seems to only update when there is a different ReShade DLL version. I tested the following:

1. Install ReShade with and overridden ReShade version of 5.9.1 (master is using this, but my branch is not)
2. Change ReShade version to ReShade 5.4.2 (previous ReShade version I had installed) with ReShade Update disabled
3. Launch game, ReShade version is still 5.9.1 and the DLLs in the game files were not updated
4. Enable ReShade Update
5. Launch game, DLL is overwritten, and the ReShade menu in-game tells me that I am using v5.4.2, and also that this is outdated and that I should update
6. Change ReShade version back to 5.9.1, but once again with ReShade Update disabled
7. Launch game, DLLs are still untouched and ReShade menu still says I am using the outddated v5.4.2
8. Enable ReShade Update
9. Launch game, DLLs are marked as updated and the ReShade menu tells me that I am using ReShade v5.9.1

Throughout all of this as well, the ReShade.txt file was updated as expected, so I think we're good on that front as well.

Unsure if I perhaps fixed something somewhere along the way to resolve the problem but let me know if that scenario I tested is wrong and I need to try something else 🙂

[sonic2kk]

I refactored the architecture check to be a bit cleaner, since with the new custom DLL name logic we use a loop to copy the DLLs. Instead of repeating this code, we can set which architecture of ReShade DLLs to copy from the source folder to the destination folder (and the architecture of the d3d47 DLL). This is just a bit cleaner and doesn't appear to have broken anything.

The code should be good now I think, pending some further tests from yourself if you have time. If you don't or if you're happy enough with the state of the PR I am ready to merge once I get the wiki updates sorted :-)

[zany130]

User does a fresh ReShade install with dxgi.dll as the default. This is moved into the game files and is written to ReShade.txt
ReShade isn't working, user realises this is a mistake, and decides to rename the DLL to opengl32.dll
The opengl32.dll is moved to the game files, and the ReShade.txt is updated to only include d3d47 and their newly selected DLL name - The previous dxgi.dll is removed from ReShade.txt, however it remains in the game files since we can't reliably know if or when it should be removed
User installs some mod that uses dxgi.dll as the modloader DLL, which overwrites the still-existing but untracked ReShade dxgi.dll
User installs some mods, then realises "uh oh, I spent 50,000 hours modding this game and lighting no longer works, what should I do?!" - They identify ReShade as a possible culprit and disable ReShade
STL will mark all tracked DLLs in ReShade.txt to be suffixed with .dll_off - Since the ReShade.txt no longer includes the now-overwritten dxgi.dll, it will be left out and ONLY the DLLs entered for the ReShade DLL name box (and d3d47) will be suffixed with .dll_off.
So now as of the latest commit, we will only track ReShade DLLs that are entered into the ReShade DLL name box, and d3d47, so that the above scenario worked. If not for that, any superfluous DLLs that the user had ever previously entered, would be marked with .dll_off, even if they did that a long time ago by mistake. Now, we only track the entered ReShade DLL names, which is logical IMO.

Exactly. Yeah I also thought maybe it would be a little difficult to restore dxgi.dll in my example. Untracking it is enough and the user needs to revert it themselves fwiw that is consistent with upstream I believe

Please let me know if you find any fault in this logic, because in my head I still have a nagging feeling that this may not be solid so a Second Opinion would help put my mind at ease a little :-)

it sounds good to me I will test it and let you know, but I agree every time we install reshade DLLs we want to recreate the ReShade.txt

You've helped out a lot with the ReShade stuff and I'm really grateful you're always willing to help test out. But I wanted to say that I'm not going to come back and point the finger at you if you don't catch a certain edge-case. If there's a flaw with the logic that you missed or anything else in this PR that's fine, I'm just looking for a bit of testing to give me a bit more confidence that this actually works, from someone who is a bit more experienced with using ReShade than myself.

no worries sorry I haven't really had the time to implement this my self but I use this feature often so I will be testing it now and whenever I game to 😄. Like I said in #873 these where issues that where on my mind and I intended to resolve but never got around to 😅 Though the PR as is now grew way more than what I was planing (Good Job though 👍 )

I could not reproduce the issue of the ReShade.txt missing a newline between the DLL names. Did you by any chance use a space instead of a comma for example? I believe it's mentioned in the tooltip but before this is merged this will be documented on the wiki as well, in case this is just a usage-related issue. Unfortunately, it is not really possible to check for commas and spaces though (DLL names could contain commas, but it is unlikely, though imo it is slightly more likely they could contain a space even if I also think that's just asking for trouble).

I got that issue by leaving the reshade dll box at dxgi.dll running the game then changing dxgi.dll to opengl32.dll.

So really this should be fixed by always re-creating ReShade.txt

Unsure if I perhaps fixed something somewhere along the way to resolve the problem but let me know if that scenario I tested is wrong and I need to try something else 🙂

Well, what I was testing was just leaving all reshade options enabled so enable, install, override, and update. (Now that I think about it, how was I sure it was the update function that kept replacing the .dll It could of just as easily been the override will test)

I noticed that the .dll kept jetting replaced this way.

One question I have is I noticed there is an option for opengl32.dll What about 64bit opengl games? (now that I like at the reshade wiki at https://www.pcgamingwiki.com/wiki/ReShade, I don't even see a mention for opengl64.dll are all opengl games 32bit?)

[sonic2kk]

One question I have is I noticed there is an option for opengl32.dll What about 64bit opengl games? [...] are all opengl games 32bit?

Aha! Now this is a good point. I looked into this when I started work on this PR and in the beginning I had made reference to opengl32/opengl64, as I assume these were the DLLs - It would make sense, right? opengl32 for 32bit, opengl64 for 64bit.

Windows uses the same opengl32.dll for both 32bit and 64bit DLLs (see this StackOverflow answer), and this is reflected in Wine too. However ReShade packages a 32bit DLL, most likely for compatibility between 32bit and 64bit applications - a 64bit game can still use the 32bit DLL afaik, but not the other way around. I think DOOM 2016 is probably a 64bit OpenGL game, I should test that to confirm.

Well, what I was testing was just leaving all reshade options enabled so enable, install, override, and update. (Now that I think about it, how was I sure it was the update function that kept replacing the .dll It could of just as easily been the override will test)

I'll try to reproduce it with all the options on again when I have some time, I was having trouble re-creating it but I forget now what other options I had enabled :-)

[sonic2kk]

ReShade wiki has been updated: https://github.com/sonic2kk/steamtinkerlaunch/wiki/ReShade

So aside from further tracking down the issue relating to the ReShade DLLs being updated when they don't need to be, this PR is ready to merge :-)

[sonic2kk]

Had to resolve a conflict with the file naming, the version will need to be bumped anyway before this is merged 😄

[sonic2kk]

I think I will merge this PR as-is, if there are still issues with up-to-date ReShade DLLs being overwritten when they shouldn't be we can look at that. I thought perhaps the ReShade Version Override logic might be the culprit here but I couldn't reproduce the problem, and in overrideReShadeVersion we do already set the ReShade version to the Overridden ReShade version (which makes sense, since we copy the right DLL from the right ReShade version folder).

Also, working in the ReShade code a bit more I can see more how it works and I have an even bigger appreciation for the work done to set up the ReShade Version Override code. It's a pretty cool feature I've come to appreciate from a utility perspective more as well as a code perspective.

I'll merge this PR as-is for now to avoid it getting stale. Thanks for all the feedback on ReShade in STL, any improvements I can make I am happy to :-)

[zany130]

Thanks, @sonic2kk from my testing other than reshade constantly getting updated I see no other issues. was able to play tales last night for a few hours and played around with some shaders as normal