ReShade compatibility with Special K #894
Comments
|
Historically Special K and ReShade have not worked on Linux, so it was something I believe the previous maintainer disabled. There is some comments warning about it in the code, too. I can investigate it though, it's worth revisiting. Do you know if it actually works? Special K is historically always software I have avoided like the plague due to the (previous?) creator's attitudes towards Valve and Linux users, so I have very minimal knowledge of what it offers and compatibility on Linux. |
sonic2kk
added
the
SpecialK
|
I wasn't on my PC when I wrote the above, I am now and did some code and wiki investigation. The SteamTinkerLaunch SpecialK Wiki Page (which seems fairly outdated?) notes the following:
This page has not been edited in over a year, and that was for an unrelated edit. In fact, this section was not even touched for the SpecialK rewrite that happened. In fact, it seems like this section of the wiki was added in November 2021, so almost 2 years ago! The SteamTinkerLaunch ReShade Wiki Page has a similar section warning of the same thing, but recently when I was modifying it to note the recent improvements to ReShade support, I put a note around whether this was still valid. This note was added a long time ago! It is very possible that things have changed since then, and that SpecialK and ReShade work together. The The code around ReShade has changed significantly in this time, so I would need to investigate to see if it is still valid. The conditional logic doesn't seem like it would work anymore, it seems like it would still run the regular ReShade code, so a small refactor of how and when STL detects that ReShade and SpecialK are enabled together would be needed. Though I wonder how this works for the exported DLL overrides for ReShade standalone, because we wouldn't want to export that if ReShade was being used with SpecialK, since SpecialK is responsible for injecting it... I'll need to look into that as well. I have not dug deep into your other issue yet but I appreciate you looking into these issues so much before reporting them, and making sure they're of good quality. SpecialK in STL has been almost entirely untouched in the last 10 months or so, and I'm more than willing to make improvements where possible :-) Once I dive deep into your other issue and your comments on the earlier issue for how to use SpecialK with NieR:Automata, and understand better the state of SpecialK with STL/Linux in general, I can look into how feasible this is to add. It may not be very much work to make an experimental branch with this code slightly refactored and re-enabled! I'll check this as well over the next few days hopefully. |
|
I did the refactor and pushed the changes to a branch which re-enables the ReShade DLLs: All the code currently does is move the ReShade DLLs with their untouched names, I should also note that automatic ReShade updating ( If you're willing to test, it should be possible to install this branch of SteamTinkerLaunch in a couple of ways, most involve temporarily uninstalling the AUR package (should preserve
You'll be able to tell that you're using the right SteamTinkerLaunch version because the version on the main menu will have the branch name in it, and also the logfile will mention the version with the branch name as well ( I will also say that right now this is basically entirely untested. This could be a big mistake with problems ranging from manual intervention being required to remove the relevant ReShade files from the game directory, or something utterly catastrophic like 2B being unable to pet Pod 042. Basically, this is untested, I just did a small refactor to fix the conditional logic, updated some logging, and did a |
|
I switched to the new branch, and things didn't blow up afterwards, so it's a win for now 😆 Once #896 gets merged, I should be able to do more testing 👍 |
|
#896 has been merged, a risky, uncaffeinated 2am merge (which seems to be increasingly common these days 🤔) but it should be fine (the diff was only so big because I unindented a bunch). |
|
Ah wait I'm dumb, the changes haven't been merged into the ReShade branch yet. I'll do that now, so that the code on the branch includes the fixes from #896 (basically it's still on an older revision of the code). |
Got it. I'll be here waiting 🙏 💜
Don't forget to take care of yourself, too 😄 |
|
There was a conflict with the branches which gave me a slight scare, but it was just the version line which causes conflicts between branches all the time, so it was easy to resolve. When you have time feel free to test and report back with, I hope, some success! As a small update from my earlier comment, the version is now |
Will do! I'll take note of the version, and do some testing 😄 |
|
I'd say it's a solid step in the right direction! The ms-api check doesn't appear, the Special K setup completes, and its UI is working in-game; all from just selecting vcredist2022 in the first run setup and re-creating the Wineprefix from the GUI. However...the ReShade dlls don't seem to be copied over to the game folder. Rather, STL appears to be trying to continuously copy the (renamed) dll into one of the steamuser directories instead. [jeremiah@arcadia ReShade]$ pwd
/home/jeremiah/.config/steamtinkerlaunch/proton/steamuser/global/Documents/My Mods/SpecialK/Plugins/ThirdParty/ReShade
[jeremiah@arcadia ReShade]$ ls -lv
total 7784
-rw-r--r-- 1 jeremiah jeremiah 277 Sep 5 19:29 ReShade.ini
-rw-r--r-- 1 jeremiah jeremiah 34 Sep 5 19:29 ReShade.txt
-rw-r--r-- 1 jeremiah jeremiah 3977952 Sep 5 19:27 d3d1
-rw-r--r-- 1 jeremiah jeremiah 3977952 Sep 5 19:22 d3d11.dll
[jeremiah@arcadia ReShade]$ [jeremiah@arcadia NieRAutomata]$ pwd
/home/jeremiah/.local/share/Steam/steamapps/common/NieRAutomata
[jeremiah@arcadia NieRAutomata]$ ls -lv
total 50268
-rw-r--r-- 1 jeremiah jeremiah 522 Sep 5 18:48 FAR.ini
-rw-r--r-- 1 jeremiah jeremiah 18207 Sep 10 2021 LodMod.ini
-rwxr-xr-x 1 jeremiah jeremiah 17837952 Sep 3 02:01 NieRAutomata.exe
-rwxr-xr-x 1 jeremiah jeremiah 17786752 Sep 3 02:01 NieRAutomataCompat.exe
drwxr-xr-x 4 jeremiah jeremiah 4096 Sep 2 11:18 SK_Res
drwxr-xr-x 3 jeremiah jeremiah 4096 Sep 5 08:24 Screenshots
-rw-r--r-- 1 jeremiah jeremiah 73 Sep 5 19:30 SpecialK_enabled.txt
drwxr-xr-x 2 jeremiah jeremiah 4096 Apr 10 04:50 Wallpaper
-rw-r--r-- 1 jeremiah jeremiah 12 Apr 15 20:36 check-steam_appid.txt
-rw-r--r-- 1 jeremiah jeremiah 4173928 Sep 5 18:48 d3dcompiler_47.dll
drwxr-xr-x 6 jeremiah jeremiah 4096 Apr 18 00:38 data
-rw-r--r-- 1 jeremiah jeremiah 11000320 Sep 5 18:48 dxgi.dll
-rw-r--r-- 1 jeremiah jeremiah 7564 Sep 5 19:00 dxgi.ini
-rwxr-xr-x 1 jeremiah jeremiah 858 Sep 3 02:01 installation_os_check.vdf
drwxr-xr-x 3 jeremiah jeremiah 4096 Sep 5 19:00 logs
-rwxr-xr-x 1 jeremiah jeremiah 242976 Sep 5 07:11 steam_api64.dll
-rw-r--r-- 1 jeremiah jeremiah 7 Apr 15 20:36 steam_appid.txt
-rwxr-xr-x 1 jeremiah jeremiah 324 Sep 3 02:01 win8_7_setup.bat
-rwxr-xr-x 1 jeremiah jeremiah 222 Sep 3 02:01 win10setup.bat
-rw-r--r-- 1 jeremiah jeremiah 343040 Sep 10 2021 xinput1_4.dll
[jeremiah@arcadia NieRAutomata]$ 524220_gamelaunch.log |
|
Thank you for testing! I guess the I did some manual testing of moving the ReShade DLLs and modifying the Once I can figure out more around the parameters on how to use ReShade and SpecialK I'll try to describe it, because a lot of the constellations I tried manually caused a crash. |
Oh no 😮 Admittedly, they both work together separately, but I feel that running ReShade through Special K has a few advantages:
So while it's not a "must-have", it's certainly nice to have, assuming that the two don't cause problems when they're loaded together like this. Just throwing that out there because I realized that I didn't put it in the description above 😅 |
|
Assuming that ReShade + Special K eventually works, I was thinking that it might open up possibilities with dgVoodoo2, in order to easily use both programs (and others?) with older games. Unfortunately, there are a few (significant?) obstacles:
Still, after reading that Special K can load it as a plugin (https://wiki.special-k.info/en/SpecialK/dgVoodoo#enable-support-for-older-graphics-api), I thought it might be useful. It might even let us give #459 a happy ending 🤔 😁 P.S. If you somehow read this, @dege-diosg: would you consider making dgVoodoo2 open source? It'd help the software community out a lot in cases like this. Someone else could work on improving the project without redoing all the hard work you put into it, and then make it available for open source projects like this 💜 🙏 |
|
The general concept here is good I think, but I don't think dgVoodoo2 specifically is very useful on Linux anymore. There is a project called D8VK (based on DXVK) that translates D3D8 to Vulkan, and it should be merged into upstream DXVK imminently. Glide/DirectDraw is already handled by WineD3D which is pretty mature and performant even if it's based on OpenGL (EDIT: mature and performant for DirectDraw and Glide), though if you really want Glide-on-Vulkan, Zink can handle that (driver as part of Mesa that runs OpenGL-on-Vulkan). Vulkan doesn't automatically mean better performance, though, so the performance gains may be minimal or there may be no gains at all. dgVoodoo2 running under Wine would essentially have to translate these Glide/DirectDraw/D3D8 calls to Direct3D 10/11 calls, which DXVK would then translate to Vulkan (D3D8 -> D3D10/11 -> Vulkan as opposed to D3D8 -> Vulkan). With WineD3D and with D8VK, this translation only has to happen once, meaning lower overhead and in principle should result in better performance - though I didn't check any benchmarks of WineD3D/D8Vk versus dgVoodoo2. It's very possible that this could result in poorer performance on Linux though, just like how Direct3D9Ex and d3d8to9 have worse performance under Wine, though the latter was occasionally needed historically in some modded games for compatibility, i.e. BetterSADX, from a pure performance standpoint I don't know of any cases where they helped performance on Linux the same way they do on Windows, because there is more overhead. In other words, dgVoodoo2 would probably add more overhead and would not be worth it from this standpoint. On top of that, what dgVoodoo2 does is already mostly possible already, and the D3D8 side will be resolved once D8VK is merged into DXVK. It would be fair to argue that dgVoodoo2 is more mature and may offer better compatibility. There could be game that dgVoodoo2 is needed for and that D8VK is not compatible with. But these cases are niche, and D8VK is in pretty good shape from what I understand. As well as this, given that dgVoodoo2 is proprietary and now archived, D8VK is still in active development and once merged into DXVK will continue getting improvements unlike dgVoodoo2, and those improvements will be specific to gaming on Linux, making D8VK more relevant to Linux gamers. In the case of compatibility it would be better to report that upstream and get those specific cases fixed rather than relying on a now-archived tool for the job. In terms of actual implementation, adding support for dgVoodoo2 would not be difficult to my knowledge. It should be a case of downloading the DLL and putting it in the game prefix, which we do for several tools (ReShade, SpecialK, IGCS, probably others). I would be off-put by the proprietary nature, but actually implementing it would be possible, it's just a case of whether or not it's useful; my stance right now is that for Linux users it is not as useful as it once may have been. Lutris offers support for installing dgVoodoo2, but this has been in place since before DXVK was a thing, and was primarily for better D3D8 performance (since D3D8 -> D3D10 -> OpenGL may have been a better combination back then, as WineD3D was better equipped to handle basic D3D10 than D3D8). Also, this is not to discredit the work that has been done on dgVoodoo2. The D8VK maintainer has credited this project as part of the development, and I'm sure on Windows the tool is very useful. I'm also very sure the maintainer put a lot of care into the project, but from a Linux gaming perspective, we have better options than we once did. The happy ending for #459 will come in the form of D8VK being available in upstream DXVK :-) |
I...did not know about all this. But this is great! You managed to answer all my concerns in a single comment 😆 The only other thing for older D3D APIs I really knew about was d3d8to9, but having something that integrates directly into DXVK will be amazing, even if it's only for a smaller amount of games relative to D3D9+. I really want to try using Zink more, but I remember it crashing games when I left it on by default. Maybe it's time to revisit some of those STL settings 😆 As always: thanks for your super informative comments. This was really the only major suggestion I had for STL; it already does a ton of stuff--usually without much issue--so there's not much more I can suggest. It sounds like you're more well-informed about the state of Linux software, in any case 😁 |
It's definitely much less, but you'd be surprised at how many D3D8 games there are (D8VK wiki page with information on compatible games, problem games, as well as a link to the full PCGamingWiki list of D3D8 games, and a full list of compatible D8VK games). I was messing around with trying to get a D8VK winetricks verb merged in and when I looked around for testing, I found a shocking amount 😄 Though several popular ones that are on Steam may not use D3D8 by default as the Steam version is an "improved" version (i.e. Hotline Miami). I should also mention that in terms of noticeable D8VK improvements, I have done minimal testing, but Touhou 6 ran much more smoothly at least. Other benefits of D8VK include the DXVK HUD being available, as well as
Heh, any improvements you can think of for STL I'm always open to hearing them. I mostly implement what I see as useful or things that I would actively use. Since there are so many options though it can be a bit tricky to stay on top of all of them, and I rely on user reports/suggestions to improve or revisit areas, like ReShade+SpecialK. Getting back to ReShade+SpecialK, to my current understanding, ReShade and SpecialK together no longer cause a crash but they also don't work together. When ReShade is enabled, the SpecialK options box is invisible when the shortcut is pressed. It will activate and the cursor will change when moved into the box, but it won't be visible. I haven't gotten a chance to fix the installation logic in #897 yet, I believe these are the steps I did manually by hand:
[Import.ReShade64]
Architecture=x64
Role=ThirdParty
When=Early
Filename=C:\users\steamuser\Documents\My Mods\SpecialK\PlugIns\ThirdParty\ReShade\ReShade64.dllDon't remember exactly if I did anything else, I remember it not consistently working or having to delete some The |
That's a huge list 😲 I was just thinking Max Payne/Deus Ex (forgot about Advent Rising, but that's one I played, too), only to find out that games like Deus Ex (Deus Ex has newer fan-made renderers, but out-of-the-box support is always great) and Soul Reaver use even older APIs! Touhou 6 was a big surprise, too--I wouldn't have known if you hadn't mentioned it 👍
I will definitely keep this in mind 👍
Hmm...I definitely remember both things working side-by-side when they were loaded individually through STL--menus and all. I nuked my saves, though, so I didn't do an in-depth test 😅
'Lazy' seems to be what the "Automatic Plugin System" uses (https://wiki.special-k.info/en/SpecialK/ReShade#automatic-plugin-system), so...might be worth a try? 😅 I'll have to see if I can try it myself with your instructions 👍 |
|
Something I forgot to note is that I'm aware of your initial suggestion to put the ReShade DLLs in the game files and get SpecialK to load it that way, but that caused a crash for me I think. I would prefer to do this because using the game files is a lot more permanent than a prefix which can be cleared. I don't think I tried putting the ReShade DLLs in the game files and then changing the path of the ReShade DLL in the INI file though (changing it from pointing to the plugins folder to basically just If this is equivalent to the Lazy load maybe there's some deeper compatibility problem 😓 |
|
So I got it working...sort of. Somehow. The main things that I found consistently need to be there are:
And that's it! Both overlays should be consistently available, and without the game crashing as well. Some other notable points:
Logs and stuff: Hope this helps! 💜 👍 |
|
Thank you a ton for all your help, I've figured out how to get ReShade and SpecialK to "work" together. This is crazy stuff, but I'll try to keep it straightforward. The steps you provided were pretty important as well. The long and short of this is there are two reasons the game will crash:
You were correct about how to put ReShade into the game files, editing the SpecialK INI is entirely unnecessary, that was a helpful step in starting to figure all this out. From there I started trying to break the problem down and figure out what defines a working state and what changes between launches. The Getting ReShade + SpecialK WorkingOkay, now for the nitty-gritty. Let's start with how to get all of this in a working state. Some of this might seem strange but bear with me. For the following, test with GE-Proton8-14 (at time of writing, latest GE-Proton): For this part, test with Proton Experimental:
Test ResultsIn doing these steps, when not using SteamTinkerLaunch, SpecialK and ReShade should work together! Unfortunately in my testing, while they do both load, the SpecialK OSD disappears after NieR:Automata goes fullscreen, and when activating it with whatever the keyboard shortcut is (Ctrl+Shift+Backspace? I can't remember off-hand even though I just did it minutes ago...) the SpecialK dialog window will be invisible. I can see that it's active because my cursor changes, but I can't see it. This is the same behaviour I mentioned before, but now I have confirmed it and gotten it to re-occur when not using ReShade as a specified plugin. I think this is something specific to my setup, as you showed in your screenshot that this is working on your end and displaying the SpecialK dialog properly. For giggles, I tried installing ExplanationThe two components here causing problems are the The other component is Interestingly, ReShade INI fileThe The D3D DebacleThe GE-Proton8-14 takes a different approach, in the interest of compatibility. There's a set of media decoding libraries on Linux called GStreamer, and they're separated into multiple packages. The one we're interested in is The SpecialK+ReShade+SteamTinkerLaunch (on master)Using these three programs with SteamTinkerLaunch is problematic for two reasons (assuming you are installing ReShade and SpecialK together):
By doing a lot of really hacky changes in the code locally I was able to stop SteamTinkerLaunch from doing these steps and I got ReShade and SpecialK to work together. This is not something that would be PR-ready by any means, it isn't a solution, but it helped me understand what SteamTinkerLaunch was doing to break things. And in short, it's some ReShade detection logic conflicting. As it stands right now, even with #897, ReShade+SpecialK cannot be used together with SteamTinkerLaunch as out-of-the-box as I would like, and may require regular manual intervention on each boot or with a Proton version change. But that's no fun, who doesn't want to use SteamTinkerLaunch?! 😉 We need a path forward for getting these two to be friends with SteamTinkerLaunch. How to Fix?So we know now that to get things working normally, we need to get the ReShade INI to use the proper line endings. To fix things, the first step is to install ReShade differently when using SpecialK. This should not be too difficult as we just have to copy the DLLs un-renamed into the game files -- We don't have to edit the SpecialK INI at all. The ReShade issue shouldn't be too much of a problem if we install ReShade with SteamTinkerLaunch, as if we have ReShade + SpecialK on, we should properly know when we have installed ReShade. The problem comes with the Having a checkbox for this option is also tricky too, because then we would have to forego the automatic detection of GE-Proton (having a dynamic checkbox like this could be tricky). It may not be clear to a user when to use it, and while it should be documented on the wiki, it is a very bizarre problem that we're essentially hacking in a way to work around. So basically, we need to know how best to handle
CaveatsThis doesn't cover the issue I'm having where the SpecialK UI doesn't show up. It's something we'll need to document on the wiki at least, but if it's affecting me it's not out of the question that at least one other user could run into this. I think even when we implement this feature request we should still keep the caveats that ReShade+SpecialK can be problematic, just to cover ourselves 🙂 There's a concern that, when writing out to the ReShade INI, the line endings could change again. We may need to modify the ReShade line endings on each game launch with Finally, I only tested with Proton 8.0-3 (briefly, it has the same behaviour as Experimental), Proton Experimental, and GE-Proton8-14. I didn't try older GEs, I didn't try Proton Hotfix, or Proton Experimental with the Bleeding Edge beta, or any Proton-tkg builds. To be honest, I would be scared to find out how those behave... 😓 So in the end, ReShade and SpecialK do work together now. In fact, it may have always worked, and the compatibility was just due to these weird parameters required to get it to work. It may have seemed like they don't work together and always crashed, because getting them to work requires different and specific steps (and currently it has to all be done manually Okay, I spent well over an hour collating all this and writing it out, and I've probably missed something silly, but I hope this was insightful and useful. And hopefully you can reproduce the same results I can, but those are my findings for now. It seems we're onto a path of getting ReShade+SpecialK to at least not crash games when used together. I'll probably heavily rework #897 because more work will be needed to get these two to work than just uncommenting the code written previously. I see a future for SpecialK+ReShade in SteamTinkerLaunch :-) |
|
Wow. That's a...lot to digest 😄 I've skimmed through it (no disrespect intended to your time and efforts), but there was something I wanted to mention.
Besides crashes, I actually was getting the invisible Special K UI pretty frequently--usually when I was editing dxgi.ini, per the wiki. I guess I just didn't think a screenshot of an invisible UI was worthwhile 😅 All that is to say: you and I both experienced the same problem, but I guess I forgot to mention it 😳 But yeah, this whole thing is completely bonkers. If you're still curious, though: it is Ctrl+Shift+Backspace. Forgetting stuff I just did happens to me, too 😂 If you'll allow me another distantly-related tangent: apparently someone semi-recently started working on vkShade, a vkBasalt fork that focuses on ReShade compatibility (link here: https://github.com/ralgar/vkShade). Likely not much there yet, but I figured that I'd put it on your radar to see if it has potential. Hopefully, it won't be as complex as this issue 😆 One last thing:
You still want me to test these two, right? It reads like it, but it also seems like you got your answer as well, so I'm not 100% sure 🙏 |
|
If you have some time and are willing absolutely feel free to test! It might give a bit more confidence to the goal of adding SpecialK+ReShade to know these steps are reproduceible and isn't a case of "it works on my machine" 😅
Hmm, I wonder what causes it... I would normally suggest reporting it upstream, but I'm not so sure upstream is friendly to Linux users (previous maintainer's forum threads were marked as spam for example).
This looks very neat! It should be very straightforward to add support for this if it takes off (and would solve the issue of ReShade not working for Linux games). ReShade+STL already work standalone but just not with SpecialK, though this would resolve it. From looking at the wiki, if one was to build it right now, it could still be used with STL by adding I think at the very least, implementing support for ReShade+SpecialK (as in, not just disabling it like we do now) would be useful, and in future if someone figures out a way to fix the invisible UI (either via a Proton/maybe more along the lines of DXVK/etc fix) then we will have support. We can document the invisible UI on the wiki as a known issue with no solid workaround yet, and note that using ReShade and SpecialK is not advised. Maybe at some point in the future we will be able to advise using vkShade in place of this! |
Sure. I'll give it a try after I rest my mind for a bit.
You're welcome! I had totally forgotten that vkBasalt/vkShade weren't limited to Linux 😅
We went from "deprecated" to "sorta working", so that's fine with me 👍
I totally support this. The more high-quality native programs we can use, the better, IMO 👍 |
|
I have sort of fixed the invisible UI by renaming from
The OSD for ReShade doesn't show up on boot, only the one for SpecialK, but pressing Home will still open ReShade, and Ctrl+Shift+Backspace also opens the SpecialK menu. However this creates a [GENERAL]
EffectSearchPaths=.\,.\reshade-shaders\Shaders
TextureSearchPaths=.\,.\reshade-shaders\Textures
PresetPath=.\ReShadePreset.ini
[OVERLAY]
NoFontScaling=1
[STYLE]
EditorFont=ProggyClean.ttf
EditorFontSize=13
EditorStyleIndex=0
Font=ProggyClean.ttf
FontSize=13
StyleIndex=2But the one that is created after launching the game with SpecialK named as This keeps getting weirder... |
|
Found out why the new ReShade.ini makes it crash, it's the paths part of the [SCREENSHOT]
ClearAlpha=1
FileFormat=1
FileNaming=%AppName% %Date% %Time%
JPEGQuality=90
PostSaveCommand=
PostSaveCommandArguments="%TargetPath%"
PostSaveCommandNoWindow=0
PostSaveCommandWorkingDirectory=.\
SaveBeforeShot=0
SaveOverlayShot=0
SavePath=.\
SavePresetFile=0
SoundPath=Removing |
I haven't played it myself, but I guessed as much from seeing your latest release https://github.com/sonic2kk/steamtinkerlaunch/releases/tag/v12.12
I'm trying HoloCure now. It's taking a really long time to load for some reason, but I'll see if it crashes on my end as well 😁
I tried asking on their Discord. We'll have to see how it goes 🤞
Oh no. Did I open up another rabbit hole? 😅 To be honest, I think I'm getting kinda burnt out with all this 😅 Maybe I just need to take a break? 🤔 |
|
I think we can close this issue to be honest, the d3dcompiler thing is something that (seemingly?) only affects me, and it isn't directly related to this issue :-) We've cleared up 99% of this, some SpecialK-specific features aren't working and they can be investigated and tackled separately. Thanks a lot for your suggestions and active participation, I think we did really good here! If you feel it should be re-opened please do re-open, but I think we can close it as you suggested earlier on. This isn't dismissing the SpecialK OSD issue by any means, but closing this issue will help bring a close to the discussion on ReShade+SpecialK here, and once we're a bit less burned out, other issues you find can be investigated separately :-) |
|
Sorry to end this whole experience on such a low note. Just kinda lost motivation during that last bit--especially since the issue was technically resolved a little while ago.
Thanks for your help and kind words 😁 💜
Got it 🫡 Including this comment, we had 127 comments spread over 3-ish bugs and a slew of pull requests. I think we've earned a break 😁 Hope to work together with you again in the future! 💜 🙏 |
|
Just a small update on this, I revisited the d3dcompiler_47 thing today and I'm making some progress on it. I basically went with the approach of using Basically, d3dcompiler_47 was already skipped if it existed in the game files. So if When using ReShade+SpecialK, This approach also means that by default, if I have only done very light testing locally basically to ensure STL doesn't explode (a good first step for developing anything) and will do some more testing and get a PR opened soon hopefully :-) |
|
Sounds pretty cool! 😁 On the ReShade testing side, I found that I had to explicitly load the ReShade DLL in Monster Hunter: World as an "Early" plugin to get it to consistently work with Special K. [Import.ReShade64]
Architecture=x64
Role=ThirdParty
When=Early
Filename=Z:\home\jeremiah\.local\share\Steam\steamapps\common\Monster Hunter World\ReShade64.dllIt's the only game so far where I've had to do that, though 🤷 |
|
Updated the ReShade wiki with this information, as well as a link to the upstream SpecialK wiki page which also seems to suggest a similar tweak :-) |
|
Thanks! 💜 🙏 |
|
It's super weird to come back to this again, but it looks like Special K (in one of its nightly releases) recently added something new to its support for ReShade: Unfortunately (?), I can't really test it out, because it conflicts with the ReShade INI that Steam Tinker Launch copies in: Since this feature is new, I assume there's not a..."Special K ReShade INI compat" option there, right? What do you think? Does this option seem like it's worth supporting? 🤔 Thanks as always! 😁 |
|
Thanks for keeping me posted on this! While I think a "Special K ReShade INI compat" option might not be the right name, how about an option (on by default) to disable creating a ReShade INI? This could be generally useful, if a user would rather insert their own for any reason, including for this new SpecialK option. I think this option should be on by default (which preserves existing behaviour and would be better to keep imo). I don't know if this option should remove an existing ReShade INI though, that could be a bit problematic. A user could manually remove / rename the existing INI from the game files, then disable the checkbox and the INI will not get re-created. Can you test if removing the file at runtime fixes the issue? That is, launching the game, then removing the INI from the game files, and then opening the SpecialK menu? The behaviour would then become something like this:
Am I understanding correctly that a checkbox to just disable creating a ReShade INI could also solve the issue? That could be a very straightforward fix as from a cursory glance it seems we only create the INI in one place in the code :-) |
No problem! 👍
I'm admittedly not the best at naming things 😅
Sure, that sounds fine.
Maybe a simple rename+backup might be enough? 🤔 Sometimes I'll tweak some settings and then delete the file without saving them elsewhere 🤣
Unfortunately, this didn't work--at least, not for me. Special K doesn't seem to create the INI--or even load the plugin--if I remove the INI while the game is running 😕 Thankfully, it's HoloCure, so you're welcome to see if it's the same on your end. Could just be another weird anomaly with my setup 😆
I feel like...that should work? I mean, I can't say for sure, but the tooltip mentions an "SK managed configuration", so I'd assume it'd make the INI if it's not present at launch 🤔 In other, marginally related news: it seems that the vkShade repo (https://github.com/ralgar/vkShade) was archived, and then deleted 😞 Before it was deleted, the maintainer cited Gamescope's ReShade compatibility as the reason. It sounded like they thought Gamescope's feature support would easily surpass vkShade's, so they archived the project. Not sure why it was deleted, though 😕 Anyway, that's the state of things! I feel like Special K is just about at the point where they're officially supporting ReShade, so hopefully this can simplify running games like Monster Hunter: World 🙏 Hope to hear back soon! 🙏 💜 |
|
Seems like the way forward is the checkbox then! I'll work on it probably close to the end of the year at this point (maybe squeeze in a v14.0.20231231? 😉). It's been a busy month! I'll also do some testing myself with HoloCure and a couple other games.
Before it was deleted, the maintainer cited Gamescope's ReShade compatibility as the reason. It sounded like they thought Gamescope's feature support would easily surpass vkShade's, so they archived the project. Not sure why it was deleted, though 😕 I had noticed not that long ago that it was archived, maybe a week ago at most it feels like? It was very recently that I had noticed this, I had gotten emails when the threads I commented in were closed. I had also saw that justification and can see where the maintainer was coming from, but I'm fairly sure they also mentioned that they would keep the repository archived for historical purposes. That's fairly surprising that it was removed... I hope nothing bad happened. The author is still on GitHub, and I'm not going to criticize them at all for removing it, hopefully it was a positive decision on their end though :-)
That would be pretty great. And of course I'm always willing about hearing anything that needs to be done on the STL end. I haven't had too much time recently for much development (any development time I have had has been spent on trying to plan out how to do the Non-Steam Game categories + I'll try to make some time for this before the end of the year, it may bleed into early next year though 😅 |
Yeah, definitely. Before this, I was just going to comment that it had been archived--since we both posted there--but after following the link and seeing it had been removed...hopefully everything's all right 😟
I've heard about hiding Steam games, but not adding them to any kind of favorites list. Is this a thing? Seems like it could be pretty useful if Steam supports it 🤔
Totally understand. It's the holidays, after all. Since it might be relevant for future testing, as well--I can post more a detailed summary in #968 if you want--the aftermath of the Steins;Gate testing (which still has issues, BTW) is that STL, Steam, and a few other apps have relatively new configs on my machine. I wiped out the Steam directory, too, so if something seems different from my previous comments, that might be why 😆 As always: thanks for your support and consideration on...a bunch of these issues 😅 I try to do as much as can on my own, but sometimes I don't know how to proceed, so...thanks for listening and offering advice 👍 💜 |
|
Initial, almost entirely untested, very WIP PR is up at #1000. I will hopefully get this merged before the New Year, should be a straightforward test :-) Also, this is the first 4-digit |
Thanks 😁. I'll be here to help if you need me 👍
Definitely. You, the previous maintainer, and the users--we all worked together to get here 😆 Stay strong! 😄 👍 💜 |
|
Pending some PR housekeeping and preparing wiki updates, #1000 is ready to merge, but there is a slight caveat I found. With just ReShade, the PR in my tests works as expected across three separate games (HoloCure, NieR:Automata, NieR:Replicant). By "works" I mean the game will load up with ReShade on and the INI will be created by default, and the "Create ReShade INI" checkbox won't (re-)create an INI file. If one exists however, it will not remove it. I didn't test with the latest SpecialK nightly, but I did notice that for NieR:Replicant and NieR:Automata, SpecialK will create a But either way, #1000 does prevent SteamTinkerLaunch from creating the INI, and the PR should be ready to merge soon. Once merged, anything you find with regards to how this may/may not work with SpecialK can be documented on the wiki, such as required versions, game-specific quirks if you find any that might be relevant, and perhaps there were relevant changes in the SpecialK Nightly to accompany this new feature that we will need to explicitly note as well :-) (P.S. I considered a way to manually remove a ReShade INI if we have SpecialK enabled, but a user may want to preserve this INI so I didn't want to remove it for similar reasons as to why I don't want disabling the checkbox to remove the INI. It also isn't very feasible to do it this way either, even if we did try a check to assume this was the first launch of SpecialK+ReShade and also that before launch the INI didn't exist, we have no way of knowing when SpecialK will create this INI and it could be with considerable delay, plus SpecialK may re-create it again at its will.) |
Awesome 😁
From what I understand, the current SpecialK nightly (24.1.1.2) crashes with a white screen on NieR: Automata. I had to use a custom SpecialK (modified from 23.12.27.2?) from their Discord to get it to work. Just a heads up so you don't need to rack your brain like I did trying to figure it out 😆
Also, I saw your recent comments on the PR--hope you get well soon 💜 🙏 |
|
#1000 was merged and the ReShade wiki page was updated to note the use-case mentioned in this issue (for some SpecialK usage). It can also be generally useful, for any reason (maybe a downstream program would want to insert their own INI, who knows :-)). As I noted the versions of SpecialK I used will create an INI, but this is unrelated to SteamTinkerLaunch, and I hope perhaps the INI that SpecialK generates will be more compatible in some way / maybe with these new ReShade options in SpecialK it will already or soon start to allow not generating the INI. But in my tests, outside of an external source creating the INI file, disabling the checkbox will prevent SteamTinkerLaunch from creating one :-) Happy gaming! |
Thanks! After giving it a try, I think that we're actually a bit early on this one--for once 😆 Getting the feature to work took a bit of work to setup, though, so feel free to correct me if anything sounds wrong to you. First, I had to manually add the entry for the DLL into the SpecialK INI; otherwise, it wouldn't get loaded after the program restarted. Also, IIRC, without manually entering the DLL, some games where ReShade reloaded during the game--such as with Warriors Orochi 3 Ultimate--created a ReShade INI. Naturally, SpecialK complained about an INI already being present in this case 😅 However, even after writing the DLL entry in, neither the GUI nor the keyboard shortcuts work--and this was true even with more well-behaved games like HoloCure. From looking around on the ReShade Discord, it seems like Special K's not compatible yet; we might have to wait until ReShade 5.9.3 is released to really do any testing with what's here. Still, better to be early, right? 😁 One weird thing I noticed with the Special K-created INIs, however... [GENERAL]
EffectSearchPaths=.\,.\reshade-shaders\Shaders
TextureSearchPaths=.\,.\reshade-shaders\Textures
PresetPath=.\ReShadePreset.ini
[OVERLAY]
NoFontScaling=1
[STYLE]
EditorFont=ProggyClean.ttf
EditorFontSize=13
EditorStyleIndex=0
Font=ProggyClean.ttf
FontSize=13
StyleIndex=2I'm not an expert, but I'm pretty sure Still, I don't think it's anything on your end. Just have to wait a bit more...I guess? 😅 Thanks as always! 💜 🙏 |
|
Thanks for all the testing! These do sound like a case of just being early, but I suppose that's to be expected when working with features from a nightly, it's compiled from the latest commit, and that oftentimes includes unfinished or sometimes even broken features - just in general, not saying SpecialK is broken or meaning any disrespect! (Oftentimes CI is used to try to ensure things work, but some features may still just not be ready yet).
Hmm, since STL isn't creating the INI I don't think STL is doing anything wrong here. I'm also not sure it could automate this since the idea is for STL to entirely ignore any sort of INI creation.
Not with this specific game, but I did notice that an INI was created during testing with ReShade and SpecialK. I'm not sure how to solve this but hopefully this is something that will get taken care of on the SpecialK end in some way.
Hopefully then it's nothing on the side of Wine or STL, but if there are further developments and things are working on Windows but still broken on Linux, more investigation may be needed to see if STL is doing something wrong. I don't know the intricacies of what might be required but we've come this far so I'm hoping we can get this integration to work once there is more compatibility.
In terms of the path, as you pointed out I don't think As for ReShade not working, perhaps (or rather, hopefully) this is just a case of being a bit early to the punch. I don't think there would be anything Wine-specific causing issues here, since ReShade itself is compatible and SpecialK also loads. If anything is going to be the culprit here, it will either be SteamTinkerLaunch needing to do something extra (currently not sure what that would be, if anything) or this SpecialK feature is still in-progress and has some ironing out (with potentially some of it being Wine-specific? Who knows 😄) It doesn't hurt to be early, and I'm sure at some point the option to toggle creating the ReShade INI is going to be the exact option someone needs for an entirely different purpose, so in my eyes there is no harm done here. I'm hoping once a newer ReShade version is out and maybe even a newer SpecialK version, integration works more smoothly 😄 |
|
Just wanted to give an update that the recent ReShade integration's working pretty well! I haven't tried it with a lot of the problem games from before; but most times now it either automatically loads, or can be loaded without issue from the Special K GUI. So...great work! I'll keep a lookout for anything over and above what we faced before; but for now, it's pretty smooth sailing. Thanks again! 👍 💜 🙏 |
|
That is awesome news! And thanks for all your collaboration and continued help, it's super appreciated :-) |
sonic2kk
added
the
ReShade
|
Yet another small development with ReShade + Special K 😆 It seems like the latest Special K can now run without d3dcompiler_47 🎉 Granted, I haven't thoroughly tested it, but it seems to work pretty well with the games I've tested it with. After disabling d3dcompiler_47 (and removing it from the directory) Special K sometimes shows this dialog box at the start of a game:
Which makes me think that Special K now supports DXVK natively 😁 Since you ran into a crash with d3dcompiler_47 before (#894 (comment)), I thought you might want to know about the recent change; just in case it helps Special K compatibility on your end. If nothing else: hopefully it's a break from other, more difficult issues 😆 |
System Information
Feature Description
While working through #893 and #889, I found that Special K currently has a non-deprecated way of loading (and using) the ReShade dll. Does it seem like it's worth putting into STL?
It seems like a pretty doable thing to add: just copy the ReShade dll for the correct arch into the game dir--without renaming it--and Special K will create the rest of the files itself. Maybe having a GUI option like "Special K compatibility" or "Special K plugin" or similar might work well? I don't know too much Bash, but I'm open to helping, if it's not too daunting of a task. Thanks!
Details here: https://wiki.special-k.info/en/SpecialK/ReShade#automatic-plugin-system
The text was updated successfully, but these errors were encountered: