Problems with STL, Proton-TkG, and Winesync (feat. God Eater: Resurrection)

[CartoonFan]

System Information

• SteamTinkerLaunch version: v14.0.20230921-1
• Distribution: Arch Linux
• Installation Method: AUR

Issue Description

I'm not even sure if this one is fixable 😅

God Eater: Resurrection, bundled with God Eater 2: Rage Burst (which is why it doesn't have its own Steam page) is a fun, yet Denuvo-saddled, game. No daily install limits, thankfully, but I always add DRM to my list of suspected compatibility conflicts, so I wanted to make sure the info was out there at the beginning.

In addition to needing d3dx9 and wmp (to avoid crashing and for movie playback, respectively), it also requires Winesync/Fastsync/NTsync--however you wish to call it--to avoid lagging at the in-game database/mission select/actual missions. As far as I'm aware, Valve-based Proton versions don't support Winesync, so I compiled the most recent version of Proton-TkG (8.16.r2.gb3e9ea10) and gave it a try.

As always, results were mixed 😆

While the lag went away, the in-game loading times went from <= 30 seconds to a couple minutes, which kind of nullified the benefits I gained 🫤

That part's probably more a bug for the TkG discord, though 🤔

Instead, I noticed some weird stuff that felt slightly more like bugs than feature requests:

• STL can't download a Steam Linux Runtime with Proton-TkG
• Auto-update Proton tries to change Proton-TkG to vanilla Proton
• I had to install d3dx9 and wmp to gain full functionality, which is quite rare since I've been using STL. I'm thinking that ProtonFixes couldn't find the game because it doesn't have it's own Steam page
• Had to run the game twice to install the above overrides, even after re-creating the prefix before selecting them
• The logs are...weird. The Proton log is basically empty, and the gamelaunch log has a bunch of vkd3d errors 😵‍💫

Links for game info are here:

https://www.pcgamingwiki.com/wiki/God_Eater%3A_Resurrection
https://www.protondb.com/app/460870/

Might not be high-priority, but sometimes Winesync really does make a difference, and more support for TkG stuff in STL should make testing easier 😁

ReShade has worked with this game before; however, this time, it threw a bunch of errors like these when trying to compile shaders:

18:48:56:858 [00740] | ERROR | Failed to compile "Z:\home\jeremiah\.local\share\Steam\steamapps\common\GOD EATER RESURRECTION\reshade-shaders\Shaders\RevoLUTion_MLUT.fx":
error: EF__PostProcessVS: <anonymous>:16:26: E5002: Static variables cannot have both numeric and resource components.
<anonymous>:18:26: E5002: Static variables cannot have both numeric and resource components.
<anonymous>:31:14: E5005: Function "tex2Dlod" is not defined.

It's a D3D9 game, so I really couldn't test Special K under the current setup.

Thanks as always!

Logs

460870_gamelaunch.log
GOD EATER RESURRECTION_playtime.log
steam-460870.log
460870_steamtinkerlaunch.log
460870.conf.zip
proton-tkg.cfg.zip
ReShade.log

[sonic2kk]

Hmm, the only part of this to me which seems related to SteamTinkerLaunch is this:

STL can't download a Steam Linux Runtime with Proton-TkG

SteamTinkerLaunch doesn't download the Steam Linux Runtime, it actually cannot. The Steam Linux Runtime has to be downloaded from Steam itself.

What SteamTinkerLaunch can do, is try to download the Steam Linux Runtime that a tool requires. Each tool notes in its toolmanifest.vdf (inside it's directory, so in the root Proton-tkg folder you should find this). On the Main Menu there is a button which will attempt to prompt you to download this tool from Steam.

However, it is very possible that Proton-tkg, especially a self-compiled one, does not use the Steam Linux Runtime. You should check for a toolmanifest.vdf inside the compatibilitytools.d/proton-tkg-folder-name. If this file exists, check if it has a require_tool_appid.

Auto-update Proton tries to change Proton-TkG to vanilla Proton

Is this when you try to launch a game, or is this an option somewhere in STL? I haven't seen this option before but if this is a checkbox somewhere, it sounds expected to me. Auto bumping to the latest Proton sounds to me like it should try to use the latest vanilla Proton. I could be misunderstanding though.

I had to install d3dx9 and wmp to gain full functionality, which is quite rare since I've been using STL. I'm thinking that ProtonFixes couldn't find the game because it doesn't have it's own Steam page

SteamTinkerLaunch doesn't use Protonfixes, I guess Proton-tkg does? I thought only GE-Proton used.

Had to run the game twice to install the above overrides, even after re-creating the prefix before selecting them

Could just be Winetricks being fussy, or the prefix being re-created with a different Proton version (i.e. not Proton-tkg), then getting corrupted and having to be re-created when running with the new Proton version (common enough with Proton-tkg). You mentioned an issue with STL trying to switch the Proton version, so it is possible that this is causing it 🤔

ReShade has worked with this game before; however, this time, it threw a bunch of errors like these when trying to compile shaders:

I'm not sure if this is related to SteamTinkerLaunch, maybe you need a different ReShade version or maybe it is broken with Proton-tkg? I'm not sure.

You should also check that since it's a d3d9 game, that you're using the correct ReShade DLL name (d3d9.dll).

The logs are...weird. The Proton log is basically empty, and the gamelaunch log has a bunch of vkd3d errors

Given that this is a D3D9 game, that is really weird! 😅

Might not be high-priority, but sometimes Winesync really does make a difference, and more support for TkG stuff in STL should make testing easier

It should support TkG no problem, I have a build of (pre-built) TkG Proton that I use with one game and it works fine. This seems like a problem with using a specific, fussy game and isn't directly related to SteamTinkerLaunch, but I could be missing something.

---

I'll try to look into the logs later today after work :-) It's possible I'm just missing something and there's some issue with STL and Proton-tkg that hasn't been caught yet (or a regression happened somewhere).

[CartoonFan]

Sorry for not being as thorough as usual. I guess those loading screens really drained me 😆

Hmm, the only part of this to me which seems related to SteamTinkerLaunch is this:

STL can't download a Steam Linux Runtime with Proton-TkG

SteamTinkerLaunch doesn't download the Steam Linux Runtime, it actually cannot. The Steam Linux Runtime has to be downloaded from Steam itself.

What SteamTinkerLaunch can do, is try to download the Steam Linux Runtime that a tool requires. Each tool notes in its toolmanifest.vdf (inside it's directory, so in the root Proton-tkg folder you should find this). On the Main Menu there is a button which will attempt to prompt you to download this tool from Steam.

However, it is very possible that Proton-tkg, especially a self-compiled one, does not use the Steam Linux Runtime. You should check for a toolmanifest.vdf inside the compatibilitytools.d/proton-tkg-folder-name. If this file exists, check if it has a require_tool_appid.

Found it:

toolmanifest.vdf.zip

"manifest"
{
  "commandline" "/proton run"
  "commandline_getnativepath" "/proton getnativepath"
  "commandline_getcompatpath" "/proton getcompatpath"
  "commandline_waitforexitandrun" "/proton waitforexitandrun"
}

That's the entire file. No 'require_tool_appid' that I can see 🤷

Auto-update Proton tries to change Proton-TkG to vanilla Proton

Is this when you try to launch a game, or is this an option somewhere in STL? I haven't seen this option before but if this is a checkbox somewhere, it sounds expected to me. Auto bumping to the latest Proton sounds to me like it should try to use the latest vanilla Proton. I could be misunderstanding though.

See, this is what happens when I don't double-check before creating an issue 😅

It's "Auto last Proton", inside STL. Enabling it makes STL try to switch to the latest vanilla Proton.

I had to install d3dx9 and wmp to gain full functionality, which is quite rare since I've been using STL. I'm thinking that ProtonFixes couldn't find the game because it doesn't have it's own Steam page

SteamTinkerLaunch doesn't use Protonfixes, I guess Proton-tkg does? I thought only GE-Proton used.

Interesting. I've been using Proton-GE for so long that I guess I didn't notice. I re-discovered STL's tweaks repo (https://github.com/frostworx/steamtinkerlaunch-tweaks); is that still recommended to use? I could probably just add a conf file if the game really needs to have the overrides installed.

Had to run the game twice to install the above overrides, even after re-creating the prefix before selecting them

Could just be Winetricks being fussy, or the prefix being re-created with a different Proton version (i.e. not Proton-tkg), then getting corrupted and having to be re-created when running with the new Proton version (common enough with Proton-tkg). You mentioned an issue with STL trying to switch the Proton version, so it is possible that this is causing it 🤔

Could be 🤔

The thing that stuck out to me was how quickly the launch process went. Normally, installing DLLs through Winetricks takes a significant amount of time; but during the first game launch, the package installation finished almost instantly, and the game crashed at the end of the launch process, which makes me think that something went wrong somewhere.

ReShade has worked with this game before; however, this time, it threw a bunch of errors like these when trying to compile shaders:

I'm not sure if this is related to SteamTinkerLaunch, maybe you need a different ReShade version or maybe it is broken with Proton-tkg? I'm not sure.

You should also check that since it's a d3d9 game, that you're using the correct ReShade DLL name (d3d9.dll).

d3d.dll is in the directory:

When it worked previously, I didn't notice any ReShade-specific issues. Neither of the in-game depth buffers were ideal, but this is very likely an issue with the game itself.

The logs are...weird. The Proton log is basically empty, and the gamelaunch log has a bunch of vkd3d errors

Given that this is a D3D9 game, that is really weird! 😅

Right? Normally, there's something helpful in one of those--for those who know what they're looking at--but if there's nothing there, then...it's not much help to anybody 🤷

Might not be high-priority, but sometimes Winesync really does make a difference, and more support for TkG stuff in STL should make testing easier

It should support TkG no problem, I have a build of (pre-built) TkG Proton that I use with one game and it works fine. This seems like a problem with using a specific, fussy game and isn't directly related to SteamTinkerLaunch, but I could be missing something.

I'll try to look into the logs later today after work :-) It's possible I'm just missing something and there's some issue with STL and Proton-tkg that hasn't been caught yet (or a regression happened somewhere).

Sorry for the confusion 🙏

I try to make things as helpful and accurate as I can, but sometimes just getting everything together and writing the issue takes a lot, so...sorry about that 🙏

I might also be forgetting something important, so feel free to ask me if things are still unclear.

[sonic2kk]

Thanks for the clarification!

That's the entire file. No 'require_tool_appid' that I can see 🤷

That is pretty interesting, it seems Proton-tkg doesn't use the Steam Linux Runtime. I just checked mine and yup it looks identical to yours.

I recall a note before plastered over the Proton-tkg readme that they don't build against the Steam Linux Runtime, but I can't find it now.

Something that would be interesting to check, really just out of morbid curiosity, is how the size of your Proton-tkg install compares to a GE-Proton install. Since you built it yourself, if I recall from my own days of building Proton-tkg, it should be around a gig? Or at the very least, noticeably bigger than a GE-Proton install.

If this is the case it's probably that it's building against your system libraries, which would make sense since I doubt it clones the Steam Linux Runtime and builds against that (TkG has his own build system, which is the shell script you run to build it, and the GitHub Actions build).

It's "Auto last Proton", inside STL. Enabling it makes STL try to switch to the latest vanilla Proton.

Somehow, I have never seen or used this option. I'll check the code later and get back to you on this one, this part could be a bug, I'm not sure what it's meant to do -- The joys of maintaining a large program, even after almost a year there are still plenty of areas I haven't touched (I have nightmares about the Depressurizer code, shudder).

The thing that stuck out to me was how quickly the launch process went. Normally, installing DLLs through Winetricks takes a significant amount of time; but during the first game launch, the package installation finished almost instantly, and the game crashed at the end of the launch process, which makes me think that something went wrong somewhere.

This is also a definite possibility. Something which occurred to me is that your Winetricks could be out-of-date. Winetricks usually only releases a new version about once a year, though it gets regular updates to fix packages and so on. To update it, you have to run winetricks --self-update (or sudo winetricks --self-update if it's installed as a system package). If you haven't tried this, it may resolve your issue.

Depending on the Winetricks, they can vary in the time it takes to install. d3dx9 should be reasonably fast, but any wmp verb can take, well, an eternity and that's if you're lucky! So for it to install basically immediately is definitely suspicious, at least to me. That's a good catch.

I still think it could be related to the Proton version change. I think going between the vanilla Proton and Proton-tkg builds have messed something up here. When installing Winetricks with vanilla Proton it's most reliable* to use the Steam Linux Runtime for verbs that run installers (ones that just force DLL overrides in the registry are pretty safe). STL currently doesn't do this with Winetricks, and it makes installation fail sometimes (motivation behind #860). When using two different Proton versions, especially two that are very different (vanilla Proton and Proton-tkg), this could be especially problematic:

• Prefix created with Proton-tkg
• Attempt to use vanilla Proton to install Winetricks, using the libraries from a much newer Proton-tkg
• Incompatibilities arise between the libraries used, or the prefix is overwritten entirely (Proton labels prefixes it doesn't recognise as 'corrupt' and creates a fresh one), and fails to install the Winetricks as it lacks the Steam Linux Runtime

Without the Auto Last Proton option, if you can ensure that Proton-tkg is used to install the Winetricks, maybe that will fix things? Since it doesn't use the Steam Linux Runtime. Then again, it's also possible that the Winetricks verbs are incompatible with the version of Wine that Proton-tkg has been built against (8.16 / 8.15 staging).

*I have only tested and researched briefly, and it appeared that dotnet48 installed more reliably with the Steam Linux Runtime. I believe Protontricks also uses the Steam Linux Runtime when installing, if available.

I re-discovered STL's tweaks repo (https://github.com/frostworx/steamtinkerlaunch-tweaks); is that still recommended to use?

Aside from using it to link to the Yad AppImage, I have never used this repository. It may work, the configs may just be a little outdated, but I can't say I've used it or heard of others who have used it 😅 I can't comment much one way or the other, sorry about that.

When it worked previously, I didn't notice any ReShade-specific issues. Neither of the in-game depth buffers were ideal, but this is very likely an issue with the game itself.

Do you know if the game used d3d9.dll back then too? Maybe the DLL name needs to be different. The ReShade version may have changed since the last time you tested, so feel free to force an older ReShade version and see if this is maybe an issue with the game.

I might also be forgetting something important, so feel free to ask me if things are still unclear.

Will do once I find something and have more to report!

---

This seems like quite an interesting issue, you certainly catch the good edge cases 😅 I still haven't gotten much of a chance to dig deep into the logs to try find out what has went wrong. To be truthful here, I just installed a brand new 7900XTX after work and I'm still playing around with it, but I will try to make this a priority to at least investigate over the weekend :-)

[CartoonFan]

Thanks for the clarification!

No problem! I want to make the issue as easy to understand as possible 😁

That's the entire file. No 'require_tool_appid' that I can see 🤷

That is pretty interesting, it seems Proton-tkg doesn't use the Steam Linux Runtime. I just checked mine and yup it looks identical to yours.

I recall a note before plastered over the Proton-tkg readme that they don't build against the Steam Linux Runtime, but I can't find it now.

Something that would be interesting to check, really just out of morbid curiosity, is how the size of your Proton-tkg install compares to a GE-Proton install. Since you built it yourself, if I recall from my own days of building Proton-tkg, it should be around a gig? Or at the very least, noticeably bigger than a GE-Proton install.

Finally, something that I can actually answer 🤣

GE-Proton is 1.3 G, and both my self-built (second folder, latest wine-staging) and pre-built (third folder, built against current valve proton-experimental-bleeding-edge tree) Proton-TkG versions are 1.1 G. The size seems...pretty close to me?

The size difference between GE and TkG might be partly due to lib32-gstreamer not compiling correctly right now. Liblc3 is the latest library to not have a 32-bit version, which makes the compilation fail. A couple of other compiled media options (ffmpeg and faudio) depend on gstreamer, so, all together, that might account for the ~200 M difference.

If this is the case it's probably that it's building against your system libraries, which would make sense since I doubt it clones the Steam Linux Runtime and builds against that (TkG has his own build system, which is the shell script you run to build it, and the GitHub Actions build).

It's building against my system libraries...I think 👀

It's "Auto last Proton", inside STL. Enabling it makes STL try to switch to the latest vanilla Proton.

Somehow, I have never seen or used this option. I'll check the code later and get back to you on this one, this part could be a bug, I'm not sure what it's meant to do -- The joys of maintaining a large program, even after almost a year there are still plenty of areas I haven't touched (I have nightmares about the Depressurizer code, shudder).

Well, since you brought it up...Depressurizer looked like it'd be pretty useful for organizing my Steam library, but the UI was not quite...as functional as I expected. I remember a lot of lag, the window not refreshing, some specific quirk with the file chooser...and on top of all that, I couldn't even apply the changes to my Steam library 😞

I'd probably try it again if I could work with it, though. For now...I feel the user side of your pain 💜

The thing that stuck out to me was how quickly the launch process went. Normally, installing DLLs through Winetricks takes a significant amount of time; but during the first game launch, the package installation finished almost instantly, and the game crashed at the end of the launch process, which makes me think that something went wrong somewhere.

This is also a definite possibility. Something which occurred to me is that your Winetricks could be out-of-date. Winetricks usually only releases a new version about once a year, though it gets regular updates to fix packages and so on. To update it, you have to run winetricks --self-update (or sudo winetricks --self-update if it's installed as a system package). If you haven't tried this, it may resolve your issue.

Winetricks seems like it's at the latest version:

arcadia% winetricks --version
20230212-next - sha256sum: cf1e17a69db4126779e597def9facdecbb0703a20ed7172dd877b1f7824d66ec

Depending on the Winetricks, they can vary in the time it takes to install. d3dx9 should be reasonably fast, but any wmp verb can take, well, an eternity and that's if you're lucky! So for it to install basically immediately is definitely suspicious, at least to me. That's a good catch.

Thanks 👍

I still think it could be related to the Proton version change. I think going between the vanilla Proton and Proton-tkg builds have messed something up here. When installing Winetricks with vanilla Proton it's most reliable* to use the Steam Linux Runtime for verbs that run installers (ones that just force DLL overrides in the registry are pretty safe). STL currently doesn't do this with Winetricks, and it makes installation fail sometimes (motivation behind #860). When using two different Proton versions, especially two that are very different (vanilla Proton and Proton-tkg), this could be especially problematic:

* Prefix created with Proton-tkg

* Attempt to use vanilla Proton to install Winetricks, using the libraries from a much newer Proton-tkg

* Incompatibilities arise between the libraries used, or the prefix is overwritten entirely (Proton labels prefixes it doesn't recognise as 'corrupt' and creates a fresh one), and fails to install the Winetricks as it lacks the Steam Linux Runtime

This might be part of the problem--the Winetricks GUI (through STL) defaults to GE-Proton-8-15:

I remember having GE-Proton-8-15 as the Winetricks prefix while using Proton-TkG as the game prefix, but I can't remember if that was the case when it failed 😞

Without the Auto Last Proton option, if you can ensure that Proton-tkg is used to install the Winetricks, maybe that will fix things? Since it doesn't use the Steam Linux Runtime. Then again, it's also possible that the Winetricks verbs are incompatible with the version of Wine that Proton-tkg has been built against (8.16 / 8.15 staging).

With the above setting (as well as all the prefix-switching going on), it really might have broken things somehow. I haven't been able to reproduce this yet 😥

*I have only tested and researched briefly, and it appeared that dotnet48 installed more reliably with the Steam Linux Runtime. I believe Protontricks also uses the Steam Linux Runtime when installing, if available.

I re-discovered STL's tweaks repo (frostworx/steamtinkerlaunch-tweaks); is that still recommended to use?

Aside from using it to link to the Yad AppImage, I have never used this repository. It may work, the configs may just be a little outdated, but I can't say I've used it or heard of others who have used it 😅 I can't comment much one way or the other, sorry about that.

That's quite all right. I will keep that option in mind if...I need to do something besides Winetricks, I suppose🫤

When it worked previously, I didn't notice any ReShade-specific issues. Neither of the in-game depth buffers were ideal, but this is very likely an issue with the game itself.

Do you know if the game used d3d9.dll back then too? Maybe the DLL name needs to be different. The ReShade version may have changed since the last time you tested, so feel free to force an older ReShade version and see if this is maybe an issue with the game.

This was...a day or two ago, I think? I'm pretty confident it was the latest version of d3d9.dll, but my testing rigor was lacking once again, unfortunately. Could somehow have been due to a dirty prefix or similar 🤔

It's more a discussion for #894, but how would ReShade + Special K work with D3D9? I'd assume they can't both use the same DLL, so I'd imagine it'd be d3d9.dll (Special K) + ReShade(64|32).dll...which might have the setup issues we discussed there previously 😅

I might also be forgetting something important, so feel free to ask me if things are still unclear.

Will do once I find something and have more to report!

Got it🫡

This seems like quite an interesting issue, you certainly catch the good edge cases 😅

Thanks 😁

In practice, it either feels like I'm good at breaking software with weird and unusual configurations...or it just kind of happens somehow. I assume it's good for software development, but I can't help but feel like I'm constantly bringing up multiple difficult issues or just asking for more conveniences 😆

I still haven't gotten much of a chance to dig deep into the logs to try find out what has went wrong.

Hopefully you can make more sense out of the chaos there than I can ⛏️⛑️🦺

To be truthful here, I just installed a brand new 7900XTX after work and I'm still playing around with it, but I will try to make this a priority to at least investigate over the weekend :-)

Hope you enjoy your new graphics card! 🥳

Also, I just realized that it's basically the weekend already 😅

[sonic2kk]

At the very least, it seems like the Auto Last Proton option is expected to update to the latest vanilla Proton. The code and the wiki back this up. However the naming of this isn't.. great in my opinion.

The name of the language string is GUI_AUTOBUMPPROTON, and as is convention with language string naming, the variable this corresponds with in the code is AUTOBUMPPROTON, which as noted on the wiki, has the behaviour of using the most recent Proton. Probably, it would be better to name this "auto bump Proton". The same should go for the GE option. Part of me thinks that perhaps this was meant to be called "auto latest"

Putting that aside, assuming the option was named correctly, is there certain behaviour you were expecting? Perhaps to choose the "newest" Proton version? I'm asking in case there's opportunity for a feature here :-)

The size difference between GE and TkG might be partly due to lib32-gstreamer not compiling correctly right now. Liblc3 is the latest library to not have a 32-bit version, which makes the compilation fail. A couple of other compiled media options (ffmpeg and faudio) depend on gstreamer, so, all together, that might account for the ~200 M difference.

Hmm, that is interesting. Good to know those details as well, that's interesting also. I guess though that Proton-tkg, possibly by design, doesn't use the Steam Linux Runtime, and this could still be causing conflicts with auto-update Proton.

[for ReShade] This was...a day or two ago, I think?

It's okay, I mean in a day or two I would forget 😅 It's hard to narrow down issues like this, however I did have a chance to check out the logs, and this part stood out to me:

Thu Sep 21 06:29:09 PM PDT 2023 WARN - checkReshade - Both 'SpecialK' and 'ReShade' are enabled.
Thu Sep 21 06:29:09 PM PDT 2023 WARN - checkReshade - This has historically caused crashes, but has been experimentally re-enabled!
Thu Sep 21 06:29:09 PM PDT 2023 WARN - checkReshade - Manual intervention may be required to fix crashes, such as renaming the SpecialK DLL to fix the SpecialK UI, or running dos2unix on INI files to fix crashes
Thu Sep 21 06:29:09 PM PDT 2023 WARN - checkReshade - For more information, see: https://github.com/sonic2kk/steamtinkerlaunch/issues/894

As you said this was working recently, and by recently I assume ReShade+SpecialK worked together recently before. Do you know if ReShade on its own works, perhaps? I noticed that v5.9.2 is being used, the default ReShade version, and in my tests only ReShade 5.4.2 was compatible (the previous default, but it was bumped over a month ago in c557406). You could try overriding the version to use ReShade 5.4.2 and see if that is more compatible.

Having said that, my memory is hazy, but I don't remember games crashing with 5.9.2, they just didn't load ReShade.

It's more a discussion for #894, but how would ReShade + Special K work with D3D9? I'd assume they can't both use the same DLL, so I'd imagine it'd be d3d9.dll (Special K) + ReShade(64|32).dll...which might have the setup issues we discussed there previously 😅

You're correct, they can't both use the DLL name. That's part of what #912 aims to solve, where you can set a custom DLL name, and set a custom export. That PR isn't quite ready yet, I don't even remember what state I left it in (it should really be a draft until I've done more testing...)

This is also what #881 aimed to solve, if there is a DLL conflict you can set a different ReShade DLL name override and export that as a DLL override yourself. It was created in part with modloaders in mind.

We sadly couldn't just have the ReShade DLL names as ReShade<bits>.dll because iirc this caused crashes.

Perhaps there is some conflict with SpecialK+ReShade here still, I am not sure. Using them together still doesn't work reliably. I also noticed from the log that it's trying to copy over d3d11.dll which is used for games with unknown render APIs. However in your game files screenshot for showing the d3d9.dll (confirmed to be ReShade32.dll from the logs), I didn't see any SpecialK-related files. So this could be entirely wrong.

For trying to fix your ReShade issue, attempting to use an older ReShade version may help. I don't know enough about how ReShade compiles shaders to help much more, but it would be interesting as well to see if it succeeds at compiling shaders with a different Proton version, if it uses DXVK to compile them? That would be a real pain to test because you'd have to flip-flop between a lot of versions, so no rush on that one really.

This might be part of the problem--the Winetricks GUI (through STL) defaults to GE-Proton-8-15:

I'll have to check to see how this version-picking logic works (I always assumed it used the game Proton, but I guess not). In the meantime, it may be worth trying to install these verbs a fresh prefix and trying to confirm if you can that you're using Proton-tkg to install them. You should be able to double-check this from the logs (Ctrl+F for Proton-tkg or winetricks could help). Just in case the Proton version is what is causing the problem here.

---

I guess the question now boils down to, what does STL have to solve here?

The main issues to my understanding here are:

• Auto last Proton option is not working as expected.
• ReShade is giving a bunch of errors with this game.
• Some Winetricks are not installing and require multiple attempts.

The main things in my mind to investigate are:

• Renaming/discussing the "Auto last Proton" feature.
  • Could just be a case of a bad naming and something we need to address.
• Seeing what can be done about the ReShade problem.
  • Since it worked previously I am unsure, but perhaps changing the ReShade version could resolve things.
• Issues related to installing the d3dx9 and wmp winetricks verbs.
  • Could be related to the Proton version used to install the Winetricks, or launch the game, or both.

Would you say those topics are a fair summary of the issue? 🙂 I'd love to blame Denuvo here, but I don't know that it's quite to blame (maybe for the loading times, who knows there heheh, but I think these issues are more related to STL/Wine than anything).

[CartoonFan]

At the very least, it seems like the Auto Last Proton option is expected to update to the latest vanilla Proton. The code and the wiki back this up. However the naming of this isn't.. great in my opinion.

The name of the language string is GUI_AUTOBUMPPROTON, and as is convention with language string naming, the variable this corresponds with in the code is AUTOBUMPPROTON, which as noted on the wiki, has the behaviour of using the most recent Proton. Probably, it would be better to name this "auto bump Proton". The same should go for the GE option. Part of me thinks that perhaps this was meant to be called "auto latest"

Putting that aside, assuming the option was named correctly, is there certain behaviour you were expecting? Perhaps to choose the "newest" Proton version? I'm asking in case there's opportunity for a feature here :-)

I was actually wondering if we could get an "Auto Latest Proton-TkG" or similar, if possible 🙏

From what I've seen, there's generally three Proton variants in common use:

• Proton-TkG (Winesync + GE patches + Proton)
• Proton-GE (GE patches + Proton)
• Regular Proton, which is, well, just Proton 😁

Proton-TkG can use the Valve Proton tree, but it's currently incompatible with Winesync--as far as I understand--so one has to build with the wine git tree instead. Because of all this, I feel like updating Proton-TkG to the latest Proton version isn't really a good fit, at present.

I guess the question now boils down to, what does STL have to solve here?

The main issues to my understanding here are:

• Auto last Proton option is not working as expected.
• ReShade is giving a bunch of errors with this game.
• Some Winetricks are not installing and require multiple attempts.

The main things in my mind to investigate are:

• Renaming/discussing the "Auto last Proton" feature.
  • Could just be a case of a bad naming and something we need to address.
• Seeing what can be done about the ReShade problem.
  • Since it worked previously I am unsure, but perhaps changing the ReShade version could resolve things.
• Issues related to installing the d3dx9 and wmp winetricks verbs.
  • Could be related to the Proton version used to install the Winetricks, or launch the game, or both.

Would you say those topics are a fair summary of the issue? 🙂 I'd love to blame Denuvo here, but I don't know that it's quite to blame (maybe for the loading times, who knows there heheh, but I think these issues are more related to STL/Wine than anything).

Yeah, this seems pretty accurate. I can't say how Denuvo plays into this, either, but it's probably not something that STL could fix...I assume. I'll have to give things another try after #894 and #919, because I've honestly forgotten what I found in this issue 😅

Sorry for the delay. My PC issues nuked the draft of this comment, so I couldn't post it as fast as I would have liked.

Thanks! 💜

[sonic2kk]

I was actually wondering if we could get an "Auto Latest Proton-TkG" or similar, if possible. From what I've seen, there's generally three Proton variants in common use

I think this makes sense. STL lets you download GE-Proton already and has support for downloading very old Proton-tkg builds when they had releases. I think it makes sense to include an "auto last TkG" or "auto-latest" as I think it's actually meant to be, but isn't because of a mistake. One consideration is how to tell what the latest TkG is, a direct string comparison may not work for the different flavours, so determining what the latest actually is might be tricky. I'll have to investigate, but we may be able to do some magic to extract the Wine version based on a few assumptions of how the TkG names should be.

Since STL has "explicit" support for using these three Proton types, auto-latest TkG shouldn't be too much of a stretch to add.

Though the Proton-tkg support in STL is dated now, it may get fixed at some point, though it's a low priority. I would like to refactor the logic to be more generic and support multiple archive types, and improve the UI somehow. I don't want to "step on the toes" too much of another project I like contributing to called ProtonUp-Qt which has much better support for downloading compatibility tools (I have contributed to the Proton-tkg and Wine-tkg support, so I'm somewhat familiar with how to implement something like this, I'd just need to do it in Bash).

Proton-TkG can use the Valve Proton tree, but it's currently incompatible with Winesync--as far as I understand--so one has to build with the wine git tree instead. Because of all this, I feel like updating Proton-TkG to the latest Proton version isn't really a good fit, at present.

I am not too familiar with Winesync but I thought it was mostly deprecated in favor of fsync, though I can see some DKMS modules which suggest Winesync can run with fsync. It's all a bit out of my wheelhouse, but this isn't the first game I've heard it benefits, though it is the first in a long time that I've heard Winesync get mentioned.

This case of a custom built TkG is a good example of why bumping Proton-tkg out in favour of vanilla Proton doesn't work, and if I can add another example (in case future me forgets, mostly), Proton-tkg is particularly useful for building Wine with custom patches, or older versions of Wine, or even specific Wine forks. The patches feature of the TkG build system, at least back in 2019-2020 time, was killer. So even if you built a version of Proton that was exactly the same as, say, the current Proton 8.0-3, just with a few patches, that still means TkG should take priority.

I think having a separate, independent option for TkG makes sense here for sure.

but it's probably not something that STL could fix...I assume.

Heh, I'm not quite that level of miracle worker yet, but one day perhaps 😉

Sorry for the delay. My PC issues nuked the draft of this comment, so I couldn't post it as fast as I would have liked.

I haven't had the PC issue, but I've encountered this problem even recently, a PR I wrote up suddenly disappeared when I tried to post it and, well, it was frustrating. But of course no problems on the delay :-)

[CartoonFan]

One consideration is how to tell what the latest TkG is, a direct string comparison may not work for the different flavours, so determining what the latest actually is might be tricky. I'll have to investigate, but we may be able to do some magic to extract the Wine version based on a few assumptions of how the TkG names should be.

Yeah, working with TkG's naming flexibility was the most difficult part, in my mind.

Though the Proton-tkg support in STL is dated now, it may get fixed at some point, though it's a low priority. I would like to refactor the logic to be more generic and support multiple archive types, and improve the UI somehow.

That's fair. I can just turn off the "Auto latest" options for the time being.

I don't want to "step on the toes" too much of another project I like contributing to called ProtonUp-Qt which has much better support for downloading compatibility tools (I have contributed to the Proton-tkg and Wine-tkg support, so I'm somewhat familiar with how to implement something like this, I'd just need to do it in Bash).

I've used ProtonUp-Qt as well 👍

Proton-tkg is there, but I couldn't find a Winesync-enabled version. Could definitely work if it just downloads the latest CI-built version.

I am not too familiar with Winesync but I thought it was mostly deprecated in favor of fsync, though I can see some DKMS modules which suggest Winesync can run with fsync. It's all a bit out of my wheelhouse, but this isn't the first game I've heard it benefits, though it is the first in a long time that I've heard Winesync get mentioned.

I think Winesync's eventually supposed to replace fsync/esync, due to games like this where they can introduce problems.

There's an issue on the wine-tkg repo that hopefully explains everything better than I can:

Frogging-Family/wine-tkg-git#936

This case of a custom built TkG is a good example of why bumping Proton-tkg out in favour of vanilla Proton doesn't work, and if I can add another example (in case future me forgets, mostly), Proton-tkg is particularly useful for building Wine with custom patches, or older versions of Wine, or even specific Wine forks. The patches feature of the TkG build system, at least back in 2019-2020 time, was killer. So even if you built a version of Proton that was exactly the same as, say, the current Proton 8.0-3, just with a few patches, that still means TkG should take priority.

I think having a separate, independent option for TkG makes sense here for sure.

Thanks 👍

I guess we both struggle with future us figuring out how we got here 🤣

Heh, I'm not quite that level of miracle worker yet, but one day perhaps 😉

That's amazing! 👀

I haven't had the PC issue, but I've encountered this problem even recently, a PR I wrote up suddenly disappeared when I tried to post it and, well, it was frustrating.

Oh no! 😟 😲

That does sound frustrating...and also quite mysterious 🤔

But of course no problems on the delay :-)

Thanks 😁 💜

I guess, while auto-updating Proton-TkG is definitely handy, the most important thing for me--besides the benefits from #894 and #919 being resolved--is having helpful logs to be able to give to you, the TkG team, or anyone else.

As usual, I'm not sure where and how to start investigating this issue 😅

I mean, it's calling vkd3d, and there's no reason I can think of for that. The logs seem to be affected by changing the debug level in STL, so I assume it's actually trying to use vkd3d--on a D3D9 game--for some reason 😖

---

I really went crazy with the emojis this time 🤣

I hope this helps things make more sense, though. I'm not a developer, so I can't always explain things 100% 😅

[sonic2kk]

That's interesting about winesync, I wonder if it's worth adding the environment variables for it under Wine options on the Game Menu, similar to the ones we expose for the GE-Proton FSR options... interesting for sure!

[sonic2kk]

No rush, just wondering if the issues discussed here are still relevant, and if so, I'll attach a "help wanted" label here.

Take your time with investigating if the issues are still present, and if so, a quick summary for anyone reading this that might be able to help (or me once I have some more capacity). As long or as short as you want, just something to give a more "current" understanding of the issues. Maybe someone a bit closer to this than I am might have some answers for you.

I realise this issue is 6 months old (sorry about that 😦), perhaps it's too stale to still be relevant, but if you still need help with it I am happy to leave it open. But because it's been so long and I don't expect a reply overnight or anything.

If no one is able to help out and I have some more free time I will try to return to this to investigate as well. I mentioned this issue on #992 to keep track of it, so I want to revisit it in some way before v14.0, either with my own investigation or if the community is able to help you out that would be awesome too :-)

[CartoonFan]

No rush, just wondering if the issues discussed here are still relevant, and if so, I'll attach a "help wanted" label here.

This is actually really great timing; there's been work at producing fastsync patches that work with regular Proton (Frogging-Family/wine-tkg-git#936 (comment)), and they might even get included in Proton-GE (Frogging-Family/wine-tkg-git#936 (comment))! 😁

I think, if/when that happens, I can start testing again. Looking at my first post, it seems like the lack of Fastsync support is the only issue here, so--assuming that everything works properly--everything should be resolved at that point 😄

Take your time with investigating if the issues are still present, and if so, a quick summary for anyone reading this that might be able to help (or me once I have some more capacity). As long or as short as you want, just something to give a more "current" understanding of the issues. Maybe someone a bit closer to this than I am might have some answers for you.

The primary issue here is that God Eater: Resurrection-- bundled along with God Eater 2: Rage Burst (https://store.steampowered.com/app/438490/GOD_EATER_2_Rage_Burst/) -- with Esync/Fsync, lags severely in loading screens and some menus, to the point where it appears to hang. If my memory serves correctly, disabling Esync and Fsync fixes the load times, but lags with the audio/visuals--though not as severely as the menu/loading lag with Esync/Fsync.

Fastsync--or Winesync, as it's sometimes called--is a newer synchronization method that solves both types of lag issues. However, it's currently incompatible with mainline Proton and Proton-GE. Proton-TkG can use Fastsync, but my self-compiled version has issues working with STL, and I'm not sure if the ProtonUp version works with Winesync (though I guess I can try testing it 😅).

Recently--as mentioned above--there's been work done in Frogging-Family/wine-tkg-git#936 to make Fastsync compatible with mainline Proton and Proton-GE. Assuming this all works out, I'm pretty confident that it would resolve this issue 👍

I realise this issue is 6 months old (sorry about that 😦), perhaps it's too stale to still be relevant, but if you still need help with it I am happy to leave it open. But because it's been so long and I don't expect a reply overnight or anything.

No, no; you're good! Actually, with all the recent Fastsync work being done, I was recently thinking about coming back to this issue and testing things again. Seems like you just beat me to the punch, though 😆

If no one is able to help out and I have some more free time I will try to return to this to investigate as well. I mentioned this issue on #992 to keep track of it, so I want to revisit it in some way before v14.0, either with my own investigation or if the community is able to help you out that would be awesome too :-)

Thanks 💜 🙏

Hopefully everything works out all right 🤞