Originally posted by ProjectXsent:

I saw that the game with Style Switcher works for them according to this link[www.protondb.com]

5 years ago...
OOF - Proton 6 :S A LOT changed code-wise ( for better or worse, mostly for the better ) since then...

I still don't have this game on Steam, so everything I say here will be without my direct testing...

Originally posted by ProjectXsent:

According to this one[www.protondb.com], it works out of the box with GE-Proton10-27 but with lack of controller support.

I mean... if a game doesn't support Steam Deck's input API natively ( this is an old game, so ofc it doesn't ), then it SHOULD still be possible to manually inject the Steam Input ( Valve's own input wrapper ), through game Steam properties ( right click on game entry in library )...
Unless the game is doing something profoundly weird, I don't really see why an additional input wrapper would be necessary ( please don't confuse this with "game detects something out of the box", this is NOT what I'm talking about ), unless I'm missing something...

PCGW ( which, as a website as a WHOLE, contains MISTAKES, and even more information is MISSING - it's a community website - so REMINDER to everyone that not everything on that website is correct! ) most basically says the game uses Dinput, but not Xinput... so I suppose an input wrapper would be necessary then...
Although on the other hand - I have never personally tried Steam Input with dinput-only games, so not entirely sure if Valve made the necessary code or not ( it might be that their wrapper outputs ONLY to xinput and literally nothing else )...

Originally posted by ProjectXsent:

Might also need to use this launch command according to the first link:

PROTON_FORCE_LARGE_ADDRESS_AWARE=1 WINEDLLOVERRIDES="d3d9,dinput8,dsound=n,b" %command%

The first link uses Proton 6 - this is SO MUCH worth of code changes there's like zero comparison in Wine behaviours...

I honestly don't know what "d3d9" is even here for...
The way Wine overrides work, is that you only ever use them if the affected library is something Wine itself already includes and you want to ensure that the file YOU want it to load is YOURS, not Wine internal one...
You generally also don't need to load game internal dlls this way MOST of the time ( the days of this being NECESSARY are generally long over, and edge cases rarely are actual games these days, mostly other software ) - so if d3d9 dll is the one in the GAME FILES, I don't see a point in loading that, over what Wine would load otherwise - according to Steam backend, the game doesn't ship with this dll in it's files - it actually ships with no dlls AT ALL.

And if someone drops a mod that uses this file, then sure, make a Wine override.

But from the way you worded everything, it would seem the only custom files dropped use dinput8 and dsound dlls - no sight of custom d3d9 dll - so if there isn't one, there's no point making a Wine override for it either...

Originally posted by ProjectXsent:

PROTON_FORCE_LARGE_ADDRESS_AWARE=1 %command%

This is one of my personal pet peeves to be honest, so please don't get offended, but I WILL tackle this one a bit...

People on Windows have tendency to "slap on LAA flag on EVERYTHING" - it's like a universal punchline on various Windows forums, from people who have very little to no clue what this ACTUALLY does...
It is almost always used as a "magical band-aid for everything", and just HAPPENS TO fix whatever OTHER problem exists with a game, that you'd normally fix a different way...
It is largely unnecessary if fixing given game CORRECTLY ( which most "people of the internet" usually lack capacity to do by themselves due to their limited knowledge ) - which is unlike what most of the internet will tell you ( and it usually comes from the same crowd which repeats like a broken record: "update your drivers", "update your BIOS", "update your Windows", as the universal "go to" for EVERYTHING - they just reiterate stuff someone else said, with zero understanding of the ramifications, which are not always positive ).


So first of all - a lot of 32bit programs, games included ALREADY HAVE the flag set.
Does this game have or does NOT have it set??
Can you check??
( again, I don't have the game, so I cannot check )


Second, Wine is absolutely NOWHERE NEAR 100% "behaviour accuracy" and API compliance with Windows...
There is A LOT of stuff that Wine does fundamentally differently ( for better OR WORSE ).
I would have to do a double take through documentation to confirm, but iirc Wine handles this flag in largely different ways than Windows itself ( iirc the "size division" is different, making the actual exe behaviour different by extension ).


Third, I faintly recall, iirc, newer Wine versions setting this flag BY THEMSELVES, already, unasked for ( which if you ask ME, I would say it's DUMB, because there are programs which BREAK from it ( see below ) and so this IMO shouldn't be the default ).


Forth, while you can get away with slapping on LAA with little to no negative consequenes for A LOT ( hundreds at the minimum ) of 32bit games and programs ( which didn't ALREADY have it set by original developers ) - it doesn't work like this for 100% of 32bit Windows software.
There ARE programs ( and some games ) which DO behave incorrectly, or outright break, if this flag is set.

Which is why I always tell privately to people I talk to, to not just slap this flag on everything "just because someone on the internet reiterated what someone else on the internet heard from someone else".
Instead, people should find the underlying problem with given game and fix it PROPERLY - but alas... I know plenty of people would get heavily offended by me pointing all of this out :P

Originally posted by ProjectXsent:

Disclaimer: I don't have knowledge about Linux/Steam OS so if you can edit and change some stuffs in the "install.sh" or the commands, that would be helpful.

I might take a look tomorrow or another day when I would find the time. No promises tho :P ;)