Shader Patch fails to launch under Linux w/ Steam Proton

[SeongGino]

Hi! I know this might not be relevant to your interests as this specifically affects only Linux users, but would still like to bring to attention--maybe if this is to run on the Steam Deck, for example.

Anyways, launching SWBF2 with Shader Patch 1.4.1 &/or 1.5.0 preview-2 causes it to crash on bootup. Log attached. Graphical representation of the error below: Seems as if it's having trouble parsing the shader files in ./data/shaderpatch/shaders/src. The game runs fine normally with just the 1.3 patch, or when Shader Patch Enabled is set to no

It's entirely fair if this isn't necessarily fixable on your end, but it would be nice to have a confirmation if this can be, or if it should be reported to Wine devs.

Running on EndeavorOS (Arch-based), Wine-6.19-GE-1.

[PrismaticFlower]

hmm, interesting that it did used to work. It certainly sounds like it was the change to supporting compiling shaders on demand that broke it. Maybe including the d3dcompiler_47.dll redistributable with it can solve it?

I've included it in the below version. When you get the chance if you could test it and let me know the results that'd be great.

shaderpatch.v1.4.1-with-d3dcompiler.zip

[SeongGino]

Oh wow, it's been a month since I've posted. Sorry about that!

I've only just gotten around to testing this; since then, Proton Experimental has updated and the reproduceable error is slightly different - the list is subtantially reduced, but obviously still there.

This is observed with releases 1.4.1 and 1.4.2, but without the packaged d3dcompiler_47. When the redistributable is provided either as a loose file implicitly loaded from your provided zip here, or installed via protontricks to the prefix, the game now quietly loads into a black screen. It only crashes to desktop a few seconds afterwards.

With it, the shaderpatch log gets slightly further, but indicates something to do with FreeType font atlas?

[PrismaticFlower]

Well it looks like it might now be making it past the shader loading. So that is good. Though whoever wrote that error message about the font atlas (me) really should've included more detail about the error. What I suspect is it's falling over on trying to load the font.

For some background (you can skip ahead if you like) v1.4 renders the game's fonts using FreeType in order to support display scaling without making the game look too terrible. The font it uses for this is Arial Black as this font matches the game's original font.

I have no idea if Wine has a mapping for that font or not. If it doesn't that would be the problem right there. The user config does control which font it'll use. If you look for this near the bottom of shader patch.yml

   Scalable Font Name: ariblk.ttf

You could try changing it to something more common like arial.ttf and see if that gets it to work. (Or alternatively the name of a font you know for sure you have installed with Wine.)

Amusingly enough today I was actually thinking about if Shader Patch should use and bundle a free font with it rather than depending on a (slightly) obscure one in Windows. This is another thing that makes me think it may be worth going down that route.

[SeongGino]

Fonts. Why did it have to be fonts?

Well, I didn't try replacing the typeface with a free equivalent, but I did install Arial through protontricks in a similar way to the d3d extension, and now it seems to work. Though, for most people who don't read logs, this is an obscure workaround and it only took you mentioning "arial black" for me to realize what was happening.

I guess, take it from this platform-jumping bozo if you'd like, but I don't think people would mind you using a bundled alternative font? Arial is pretty literal system-font-esque which was never all that appealing to begin with, so something different that works cross-platform wouldn't look that much more out of place but work for 1% more people. As well as bundling the needed extension for Proton to load implicitly without needing Protontricks, wouldn't hurt. Though, the configuration/installer tool is using .NET which is notoriously flakey with Wine - on my system prefix with dotnet46 installed, the configurator doesn't even work. It just opens like

It's been a bit since I played this on Windows, so forgive me for my ignorance but um, I don't remember sorting issues this bad?

Oh; it's suggesting my 1060 doesn't support A-OIT. Weird.

[PrismaticFlower]

Yeah I'm seriously considering adding a bundled font either as the default or a fallback, turns out the code I have for passing the game font layout information breaks in a subtle way for other fonts though. Very annoying since it means making this change isn't as simple as I was hoping for.

Though, the configuration/installer tool is using .NET which is notoriously flakey with Wine - on my system prefix with dotnet46 installed, the configurator doesn't even work. It just opens like

Aha, oops that bit in the readme is outdated. That's my bad sorry! The old installer/uninstaller did use .NET, the new rewritten one uses something that is probably even harder to use under Wine. Specifically the Windows Runtime (for it's UI). When I made that choice in my mind it was great because it didn't need people to install anything separate, it kept the binary size low and it scales with DPI without any hassle.

As mentioned in #133 I am starting to think that maybe the configurator should have it's WinRT UI code replaced with something else. Likely it would end up using ImGui instead.

It's been a bit since I played this on Windows, so forgive me for my ignorance but um, I don't remember sorting issues this bad?

Yeah I did a little testing and was able to replicate something like that in first person. (I don't often use FP so that'll be how it slipped past, annoying for sure.)

Oh; it's suggesting my 1060 doesn't support A-OIT. Weird.

Strange, I think the 1060 supports the equivalent Vulkan extension. Maybe ROVs aren't implemented in Proton yet though?

---

Sorry about the slow reply by the way!

[SeongGino]

Couldn't really blame you for any of that! I don't imagine it's often you see bug reports from Linux users for mods of Windows games running through Proton/Wine; it's just that it would be nice if more things like this were slightly more platform-agnostic.

Anyways, I was just wondering if the sorting in FPM was because of the unimplemented function, but I guess that's something else entirely then. I'll have to check with Proton &/or DXVK one of these days for this to be fixed/implemented upstream.

---

EDIT: ...As indicated by vVv below, I checked with the relevant project and they don't seem very thrilled to implement the needed function. Safe to say until anything with that changes, it's an upstream issue and unrelated to shaderpatch in particular.

[lankv2]

When launching the latest shaderpatch through proton it seems the problem is d3d9.dll. As soon as i rename it the game launches but otherwise it just crashes on launch.

[SeongGino]

@BENDER-V2 providing log files would be useful. Though as of now with a default prefix, the default shader patch.yml's choice of font will cause it to crash because Proton does not come with an equivalent to Arial Black. As it is, the user will have to either:

• Provide Arial Black, through Protontricks
• Rename Scalable Font Name to an available default font, i.e. arial.ttf
• Disable Scalable Fonts

[SeongGino]

That said, I have noticed weird artifacts popping up in 1.7.0 that weren't in 1.6.1--some of the effects like blaster fire and thermal detonators' glow and explosions are either corrupted or don't appear at all, regardless of OIT setting or effects being enabled. These effects are correct in 1.6.1 (with OIT off/ OIT on still causes these effects to not display as before, even with an up-to-date NVIDIA driver and current Proton-GE/Exp).

[SeongGino]

I meant shader patch.log, not your proton log.

[lankv2]

nvm. i was using a bad shader patch.yml after replacing it and changing the font now it works.

[PrismaticFlower]

The font crash should be fixed in v1.7.1 but scalable fonts will still not work out of the box. It'll just fallback to the game's regular ones.

[SeongGino]

Can confirm that the artifacts/corrupted effect textures were fixed too in 1.7.1.

However, might I suggest reevaluating how you package your releases? Because the file list comes out as corrupted on Linux with archive extractors/managers that use 7z; every subdirectory is treated as the file name, and some files/folders can't be removed without admin privs. To this point, the workaround has been to use unzip instead. With 1.7.1 in particular, with the aforementioned unzip program, the entirety of the data/shaderpatch/* directories are missing their contents--which, obviously, causes shaderpatch to crash on startup.

(I only got this release to work by filling in the missing files from the source repo directly, which isn't very ideal)

[PrismaticFlower]

That is annoying. I'm not sure what to switch to though. Can anyone tell me if a regular .zip made by 7-zip instead of PowerShell works? shaderpatch.zip

[SeongGino]

The 7-zip-made zip seems to show and extract just fine, yep.

[PrismaticFlower]

Good to know, thank you! I'll package it using 7-zip from now and I've updated the last release's .zip to be packaged with 7-zip as well.