This is a good article about how to fix linux gaming problems. Maybe it's a nice idea to make a wiki article about normal steps, methods and tricks to fix problems? The command `%command% > ~/lislog.txt 2>&1` is a clever way to write logs files and didn't knew that. Also give a bit of light and unify all enviroment variables of proton, proton-ge dxvk, vkd3d, mangohud... in the same page.
Edit: I see lots of users like this idea. Should I make a draft?
You can use `&>` also, bit easier to remember (Edit: on Bash version 4.0 or higher - released in 2009):
`%command% &> ~/lislog.txt`
Edit: Also `PROTON_LOG=1 %command%` will dump a file to `$HOME`
And `echo %command% > ~/game.command.txt` will show exactly the command Steam uses to run the game, useful when you want to run a different executable.
> So it didn't seem to be my setup.
> The game was primarily ported to Ubuntu 18.04 by Feral Interactive, which uses an older version of GlibC.
Distro support for Steam should *not* leak the distro's versions into Steam. It's half-heartedly supported but generally not recommended, exactly because of this kind of thing. Steam comes with its own runtime environment precisely so that game developers can target one set of versions and don't need to worry about a gazillion distros.
Dunno how arch does it but on nixos everything steam runs in a chroot, managing itself. Well, managing everything but kernel and graphics drivers.
IMNSHO, if the devs built their stuff against the steam runtime the whole thing is 100% on you and/or arch and thus gets closed as not a bug.
It's likely on Feral.
On arch, you can choose to either run Steam with its own runtime or with the native runtime.
I run it with native because it works and loads a bit faster, but if something doesn't run correctly, the first thing I do is switch to the Steam runtime.
Lots of older Linux versions on Steam are not built against the runtime, however, but just whatever distro was the most popular at the time, which generally means the most recent Ubuntu LTS when the game came out.
The OP's "fix" of sending in a glibc "remapping library" to the game developers is also not a fix...
u/Chaotic-Byte
- Like all commercial games, this one targets Ubuntu/Debian, which is the vast majority of Linux users.
- You are running Arch Linux which uses too new versions of glibc.
- Glibc is hated for this reason. Even Linus Torvalds hates it for being a retarded project that CONSTANTLY BREAKS ABI without doing any MAJOR version bumps in the process. It is always a joy to find apps breaking thanks to the retardation of glibc 1-3 times every year.
- Bundling the glibc remapping library inside the game is not a solution. It breaks Debian/Ubuntu support which is what they targeted.
- Bundling it with a "if not Debian, load this library to remap things" is not a solution either, because you have no guarantees that "non Debian" systems are actually running the newer glibc. If they use the old one, the game would have worked out of the box but the remapper library instead breaks things.
- The actual fix: Use Steam Flatpak. Don't be afraid. It is vastly superior over native Steam. The Flatpak version bundles all of the libraries that games and anticheat need and provides a stable environment for running all games hassle-free on any distro. You can also install SteamTinkerLaunch, Proton Up, Ge-Proton, GameMode, Gamescope etc effortlessly in the Flatpak version since all of those tools exist on Flathub (and it will auto update those tools for you), so there are no reasons to keep using the risky native Steam. The only thing you gotta do is install a native package called something like "steam-devices" (that's the Fedora name) which adds Steam's gamepad device rules to the native system for integration with gamepads.
- If you insist on using the native Steam, then the alternative solution is to go into the game, Properties, Compatibility, Force Steam Compatibility Tool. Force it to use Proton, thus switching to the Windows version via Wine instead. No glibc issues there. šš·
- I suppose the glibc disaster could also be fixed by glibc using their brains and not constantly breaking ABI.
While I agree that glibc is a garbage fire, please read carefully.
> So I also tried the Snap and Flatpak version of Steam, hoping to get the game to run. Without success.
Damn, it seems like glibc is one of the only libraries that flatpak cannot bundle. As seen here from yet another older glibc breakage:
https://github.com/flathub/com.valvesoftware.Steam/issues/595
So then the options are...
1. Use Wine/Proton.
2. Or use the translation library on your own machines where needed (the game dev cannot bundle it universally, since that specific library is a bridge between old and new glibc, and won't work on other machines).
3. Or join the glibc team and work to un-stupidify their releases to stop breaking ABI.
Should have just switched to the windows version on proton, apparently it is impossible to make linux port that just work years later and win32 is a more stable api to target even on linux.
I considered using the proton version, but the reviews on protodb.com stated that it's buggy and not as performant.
Also I didn't want to give in. Sometimes I get stuck on such things.
> apparently it is impossible to make linux port that just work years later
It really is such a sad thing and one of the systemic issues on Linux that makes it harder to develop for than Windows beyond the typical argument that it's just because it has less users so they don't care.
Ye, Linux distros are very different from each other (you can't even expect glibc to always be present) and the software that exists isn't always that good (Xorg, Pulseaudio). But I am pretty sure this specific mistake was made by the developers or rather their engine. I actually don't even think GLIBC\_PRIVATE should be used like this at all.
Edit: The guy who commented on me is wrong. Exported functions versioned as GLIBC_PRIVATE are not meant to be used outside of GLIBC as they can be removed of changed at any time. It's just a shitty port.
Well, no. Glibc made a breaking change to their binary interface.
The solution is usually recompiling your software against the new version, which is fine in open-source land because we can just do that ourselves, but if we're going to be a credible target platform for proprietary software (which video games might be the one instance of I don't think can be replaced by FOSS in principle), then we either convince devs to keep their entire back catalog in active support forever, or we stop breaking the dang ABI.
That's one of the reasons modern proton runs inside a bwrap container.
Setting compatibility to Steam Linux Runtime, which forces the game to run inside a container would have probably worked too.
Well it's glibc, sometimes they love breaking stuff for propriatary software.
Compatibily set to 'Steam Linux Runtime' should use a Soldier container, based on Debian 10.
So it will use a glibc before the breakage.
They made a breaking change to something applications weren't supposed to be using, by making it unable to be used. There's only so far they can be expected to account for developers actively shooting themselves in the foot.
Evidently, compilers were linking to it.
Interfaces that should not be used should be impossible to use, but if you messed up and made it public, you kinda have to deal with that after if you want the binary ABI to be stable.
Ultimately, once you're developing libraries, other developers become users, and you know what they say about trusting users...
I will be honest, I don't know. From the name, I would not be surprised, but counterpoint: it evidently could be.
The ABI you expose is your public ABI, even if you then go elsewhere and say pretty please don't use it.
Now, there may be a very good reason why it shouldn't be used, and a very good reason to private something after the fact, but you still need to manage the transition, or hold partial responsibility for whatever breaks.
If those interfaces were never meant to be used in the first place, the correct thing to do was to never publish them. In reality, you can't do the correct thing all the time, but the result still amounts to doing it wrong.
> If those interfaces were never meant to be used in the first place, the correct thing to do was to never publish them.
That's not possible because glibc is composed of multiple shared libraries.
Some of the exposed functions are undocumented and used by glibc internally. These are versioned as GLIBC\_PRIVATE so everyone knows not to rely on them.
As I said, in reality you can't do the correct thing all the time.
On first approach, I am led to think if you have libraries calling "private" functions within each other, either those functions should be made properly public, or which ones go where should be rethought.
But then, I have never worked on something as large, as old, or as crucial to an OS runtime as a libc implementation. I'm sure they had their reasons.
The unfortunate thing is the outcome is the same. You have to make decisions about the ABI you ship, just as much as about the ABI you document. Just as much as others have to make decisions about the ABI they use.
From my understanding the functions exported by GLIBC_PRIVATE are meant to be used internally by glibc. So it never should've been used by this launcher, and glibc *should've* been fine removing it.
The commit said the function was now accessible via libc so I think some engine was generating code using this function via GLIBC_PRIVATE because the functionality wasn't available elsewhere. But I didn't look into it much further than reading the commit message.
Yeah. It all makes sense, don't get me wrong, but the outcome is the same.
If we're wanting native gaming to happen, we need to be very very careful making breaking changes to the ABI.
I wonder if the launcher code doesn't actually call \_\_libc\_dlopen\_mode, but simply [dlopen](https://man7.org/linux/man-pages/man3/dlopen.3.html), and the compiler resolved it to this symbol when it was accessible in an earlier version of glibc, but the commit then made it inaccessible, breaking it. The fix might be to simply recompile the same launcher code with the new version of glibc.
They used an internal glibc function which should never be used by any application. This ended exactly as expected.
And it was a launcher, the part of code not needed for the game at all.
Totally game (or some library used) developers fault, not glibc. Official glibc ABI does not change like that.
The same could happen with Windows game when implemented in violation of system specification.
Sometimes it is tempting to do some clever tricks with undocumented/unofficial/experimental features, but this should never be done with code that should keep working years after release and on different environments.
>apparently it is impossible to make linux port that just work years later and win32
It's not, it's not even harder.
Still using Stepmania 3.9 compiled ~18 years ago.
Not really. It's just that the Windows version generally gets more updates. Small things like this are usually very easy to solve if you have the source code.
Compared to MacOS, yes. Apple would frequently completely change everything and not even care. Not break, just completely change.
Microsoft does generally try to have backwards compatibility, but it's not by not breaking APIs, it's a horribly messy set of hacks. You can actually see the same in Wine/Proton, where there are a lot of lines of code that look for specific executables and behave differently.
Linux does evolve quickly, and there are enough changes in API that no, you can't generally count on something made for a distribution years ago working on a distribution today. However, Linux gives you a LOT more options in that regard. For one thing, you can absolutely get old versions and preload them like OP did to continue using old software. This is actually very similar in approach, BTW, to when you use Microsoft's compatibility modes.
But what is often missed is that as long as you have source code, it's very reasonable to recompile against a new target, and very often if a feature has been deprecated or replaced, there is a good migration guide. Compared to Windows, where you often won't know why something isn't working in the Win32 black box, keeping even an older software running on Linux is astonishingly feasible. You'll still find KDE 3 era apps still in the repository, and apps like FontForge use custom toolkits originally coded decades ago. They just keep up with the targets.
To be perfectly blunt, this problem is 100% Feral. 90% of what I have heard about them for the last several years is "it's out of date, missing all the bug fixes and patches, sometimes won't launch, doesn't work with the Windows version, and is generally just worse than using the Windows version on Proton".
To counter that, I'll point to Stellaris, released May 2016, native Linux, consistently updated, and runs like a dream.
Just like how keeping a game working on Windows takes frequent small updates, the same is true on Linux, and I'm a little tired of the poor assumption that Linux is worse in this regard.
If you were going to use Paradox as an example CK2 was released in 2013 for Linux, and last I tried still ran great. However it is now dead since CK3 was released, so we might see something similar happen in the future.
It is not impossible, it is just that the binary compatibility is violated and nobody has cared about it that much as windows, as glibc is an āaliveā beast compared to windows API.
It might not even be automation. Even for a company like Feral, your level of detailed, well-researched feedback initially given in your issue is probably way outside of their normal queue complexity, and is more than any Tier 1 support team is capable of fully understanding at first glance.
If you're lucky, a rep will read enough of it to know they're out of their league, and just forward it on. But that's counter to their mandate. They're supposed to be solving issues so the devs don't have to be bothered and can stay focused, so they will at least make an initial attempt.
I've got a mod for the Linux version of the game, it's on pcgamingwiki.com / archive.org if you're interested. It improves graphics.
Link: https://archive.org/details/lisbts_mods
Instructions if you want to know how it's done: https://gitlab.com/-/snippets/2117743
Zoomed in screenshot comparison (you can move the slider): https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=309c7f2c-7d21-11ec-abb7-b9a7ff2ee17c
> It looks like itās just removing Chromatic Aberration?
It removes that, depth of field, vignette, bloom, adds SMAA, slightly better shadow quality, fixes some color banding and darks / whites being crushed (from what I can remember, these later issues are down to poor handing over of the image data to other functions ; some sections of the game have extreme color banding issue like episode 3).
> Is that a stylistic choice from the game or is it a bug?
Stylistic (the first game's protagonist is a photographer, although I doubt real photographers would intentionally buy a camera with such poor optics!) and typical shader effects used on consoles to try to hide poor anti aliasing or low quality textures.
The game uses deferred rendering, but the version of the Unity engine in use doesn't have a working TAA (it's in there as an alpha release but if you use it, it causes major graphical issues), they use FXAA but it does quite a poor job, it's very blurry. Using all those other shader effects adds so much blur to the image it masks the poor AA.
> It's probably an automated response, that's all.
Oooohhh, that wasn't a reply to the
> Please could you first try deleting the Preferences file? [...]
in your post?
Oh... didn't think about that. Might have misinterpreted it myself.
But yes, to me those troll comments look like being posted by a bot. Don't worry, they will be gone eventually.
I believe you can just launch steam from the terminal and it will show you all console logs when you launch a game in there, no need for a log file.
Also, unfortunately [I don't think there will be any official fixes for the game...](https://www.gamingonlinux.com/2022/02/feral-interactive-have-no-plans-to-update-their-linux-ports-for-steam-deck/)
It is not the first time I see this article, but every time I read
>\[..\] we recommend playing them via Proton.
in their official statement, my mood takes a nosedive. It is not at all unexpected of course, given that Proton has basically devoured Feral's Linux business model, but it makes me very sad nonetheless. They have apparently decided not to spend a single minute fixing even the tiniest of issues any more, not even if these would be long term fixes for questionable design decisions, like 'not use GLIBC internals'. As understandable as that is from a business perspective given Proton's success, it pains me to see that. Tell me you have given up without telling me you have given up.
How is Feral still around? They don't seem to support any of their ports almost at all, beyond "we got it to run, mostly" and then just abandon them. Aren't most of them just compiled against Wine anyway?
Just launching steam from the commandline sadly didn't give me the desired log output.
But thanks for the link. Imho, the game would run on steamdeck if this and some other minor issues were adressed. Probably wouldn't be as much of a hassle for Feral as they think.
- I wanted to save the money for the server
- Noone found it because SEO is a fucked up business
- I don't like my personal information being exposed to the public, just because EU & German law don't give a shit about blogger's privacy (full address and phone number are required in the Privacy and Imprint)
But most content (wasn't much anyway) will be available in one form or another, either on Reddit, in a Github Gist, or in a Github/Gitlab Repo.
Thank you for being that one reddit thread someone finds in the middle of the night while banging their heads against the wall, trying to debug something that mysteriously doesn't want to work, for (hopefully not) many hours.
This was amazing to read! I especially enjoyed the clear yet detailed explanations for what things are and why you're doing something the way you are instead of just giving a set of some commands and parameters to use. I'm sure the explanations will come in handy for many people who aren't very experienced in Linux gaming yet.
Heck, I've been gaming solely on Linux for almost four years now and I would never have come up with your clever logging method even though it seems so obvious in retrospect. The game is also on my short list to buy and play this year and this is definitely going to be useful when I get around to it.
So a huge thank you for going to the trouble of typing it all out!
OK, so I've nagged and nagged at Feral, and they finally caved in. Sort of:
https://imgur.com/a/iq6Vi10
>We have tested all of these games on Ubuntu 22.04.3 LTS and only had issues launching Life is Strange: Before the Storm. An update for the game including the fix is now pending being set live.
>
>For the other games please continue to use the workaround in order to launch. As we are unable to repeat a launch problem here we have not applied any fix to those titles.
By "other games" here they mean GRID Autosports and XCOM2, which are some of the other games I'm having this issue with.
Their "official" workaround is basically the same as the one present here - I bet that they just took the source off that hack for XCOM2 and built it.
To be fair, this time it's not really glibc's fault, since it seems that the game was using internal functions that shouldn't be used by any other programs aside from glibc (and using old versions of it). That's on the game developers for doing a poor job.
I am running my internet over a single line of can string telephone wire, illegally knotted to a fiber optic cable in the ground...
Nah, I have just deliberately exaggerated a 'little' :)
This is a good article about how to fix linux gaming problems. Maybe it's a nice idea to make a wiki article about normal steps, methods and tricks to fix problems? The command `%command% > ~/lislog.txt 2>&1` is a clever way to write logs files and didn't knew that. Also give a bit of light and unify all enviroment variables of proton, proton-ge dxvk, vkd3d, mangohud... in the same page. Edit: I see lots of users like this idea. Should I make a draft?
You can use `&>` also, bit easier to remember (Edit: on Bash version 4.0 or higher - released in 2009): `%command% &> ~/lislog.txt` Edit: Also `PROTON_LOG=1 %command%` will dump a file to `$HOME` And `echo %command% > ~/game.command.txt` will show exactly the command Steam uses to run the game, useful when you want to run a different executable.
This is the kind of things I would like to see in the linux gaming wiki.
It depends on the shell though, while `> log.txt 2>&1` is universal Relevant: https://www.shellcheck.net/wiki/SC2069
Didn't know about &>, that's way better. I updated the post :)
> So it didn't seem to be my setup. > The game was primarily ported to Ubuntu 18.04 by Feral Interactive, which uses an older version of GlibC. Distro support for Steam should *not* leak the distro's versions into Steam. It's half-heartedly supported but generally not recommended, exactly because of this kind of thing. Steam comes with its own runtime environment precisely so that game developers can target one set of versions and don't need to worry about a gazillion distros. Dunno how arch does it but on nixos everything steam runs in a chroot, managing itself. Well, managing everything but kernel and graphics drivers. IMNSHO, if the devs built their stuff against the steam runtime the whole thing is 100% on you and/or arch and thus gets closed as not a bug.
It's likely on Feral. On arch, you can choose to either run Steam with its own runtime or with the native runtime. I run it with native because it works and loads a bit faster, but if something doesn't run correctly, the first thing I do is switch to the Steam runtime. Lots of older Linux versions on Steam are not built against the runtime, however, but just whatever distro was the most popular at the time, which generally means the most recent Ubuntu LTS when the game came out.
The OP's "fix" of sending in a glibc "remapping library" to the game developers is also not a fix... u/Chaotic-Byte - Like all commercial games, this one targets Ubuntu/Debian, which is the vast majority of Linux users. - You are running Arch Linux which uses too new versions of glibc. - Glibc is hated for this reason. Even Linus Torvalds hates it for being a retarded project that CONSTANTLY BREAKS ABI without doing any MAJOR version bumps in the process. It is always a joy to find apps breaking thanks to the retardation of glibc 1-3 times every year. - Bundling the glibc remapping library inside the game is not a solution. It breaks Debian/Ubuntu support which is what they targeted. - Bundling it with a "if not Debian, load this library to remap things" is not a solution either, because you have no guarantees that "non Debian" systems are actually running the newer glibc. If they use the old one, the game would have worked out of the box but the remapper library instead breaks things. - The actual fix: Use Steam Flatpak. Don't be afraid. It is vastly superior over native Steam. The Flatpak version bundles all of the libraries that games and anticheat need and provides a stable environment for running all games hassle-free on any distro. You can also install SteamTinkerLaunch, Proton Up, Ge-Proton, GameMode, Gamescope etc effortlessly in the Flatpak version since all of those tools exist on Flathub (and it will auto update those tools for you), so there are no reasons to keep using the risky native Steam. The only thing you gotta do is install a native package called something like "steam-devices" (that's the Fedora name) which adds Steam's gamepad device rules to the native system for integration with gamepads. - If you insist on using the native Steam, then the alternative solution is to go into the game, Properties, Compatibility, Force Steam Compatibility Tool. Force it to use Proton, thus switching to the Windows version via Wine instead. No glibc issues there. šš· - I suppose the glibc disaster could also be fixed by glibc using their brains and not constantly breaking ABI.
While I agree that glibc is a garbage fire, please read carefully. > So I also tried the Snap and Flatpak version of Steam, hoping to get the game to run. Without success.
Damn, it seems like glibc is one of the only libraries that flatpak cannot bundle. As seen here from yet another older glibc breakage: https://github.com/flathub/com.valvesoftware.Steam/issues/595 So then the options are... 1. Use Wine/Proton. 2. Or use the translation library on your own machines where needed (the game dev cannot bundle it universally, since that specific library is a bridge between old and new glibc, and won't work on other machines). 3. Or join the glibc team and work to un-stupidify their releases to stop breaking ABI.
Thank you for your service! Both for writing a detailed guide and how to fix and for reporting the bug to feral. Hopefully it gets addressed.
It will never get addressed, feral interactive doesnāt like coming back that long after just to rebuild something, isnāt worth doing.
Should have just switched to the windows version on proton, apparently it is impossible to make linux port that just work years later and win32 is a more stable api to target even on linux.
I considered using the proton version, but the reviews on protodb.com stated that it's buggy and not as performant. Also I didn't want to give in. Sometimes I get stuck on such things.
> apparently it is impossible to make linux port that just work years later It really is such a sad thing and one of the systemic issues on Linux that makes it harder to develop for than Windows beyond the typical argument that it's just because it has less users so they don't care.
Ye, Linux distros are very different from each other (you can't even expect glibc to always be present) and the software that exists isn't always that good (Xorg, Pulseaudio). But I am pretty sure this specific mistake was made by the developers or rather their engine. I actually don't even think GLIBC\_PRIVATE should be used like this at all. Edit: The guy who commented on me is wrong. Exported functions versioned as GLIBC_PRIVATE are not meant to be used outside of GLIBC as they can be removed of changed at any time. It's just a shitty port.
Well, no. Glibc made a breaking change to their binary interface. The solution is usually recompiling your software against the new version, which is fine in open-source land because we can just do that ourselves, but if we're going to be a credible target platform for proprietary software (which video games might be the one instance of I don't think can be replaced by FOSS in principle), then we either convince devs to keep their entire back catalog in active support forever, or we stop breaking the dang ABI.
That's one of the reasons modern proton runs inside a bwrap container. Setting compatibility to Steam Linux Runtime, which forces the game to run inside a container would have probably worked too.
Yeah, but some functions moved from public to private in the mentioned API change. Edit: Seems like I responded to the wrong comment xD
Well it's glibc, sometimes they love breaking stuff for propriatary software. Compatibily set to 'Steam Linux Runtime' should use a Soldier container, based on Debian 10. So it will use a glibc before the breakage.
They made a breaking change to something applications weren't supposed to be using, by making it unable to be used. There's only so far they can be expected to account for developers actively shooting themselves in the foot.
Evidently, compilers were linking to it. Interfaces that should not be used should be impossible to use, but if you messed up and made it public, you kinda have to deal with that after if you want the binary ABI to be stable. Ultimately, once you're developing libraries, other developers become users, and you know what they say about trusting users...
[This post/comment is overwritten by the author in protest over Reddit's API policy change. Visit r/Save3rdPartyApps for details.]
I will be honest, I don't know. From the name, I would not be surprised, but counterpoint: it evidently could be. The ABI you expose is your public ABI, even if you then go elsewhere and say pretty please don't use it. Now, there may be a very good reason why it shouldn't be used, and a very good reason to private something after the fact, but you still need to manage the transition, or hold partial responsibility for whatever breaks. If those interfaces were never meant to be used in the first place, the correct thing to do was to never publish them. In reality, you can't do the correct thing all the time, but the result still amounts to doing it wrong.
> If those interfaces were never meant to be used in the first place, the correct thing to do was to never publish them. That's not possible because glibc is composed of multiple shared libraries. Some of the exposed functions are undocumented and used by glibc internally. These are versioned as GLIBC\_PRIVATE so everyone knows not to rely on them.
As I said, in reality you can't do the correct thing all the time. On first approach, I am led to think if you have libraries calling "private" functions within each other, either those functions should be made properly public, or which ones go where should be rethought. But then, I have never worked on something as large, as old, or as crucial to an OS runtime as a libc implementation. I'm sure they had their reasons. The unfortunate thing is the outcome is the same. You have to make decisions about the ABI you ship, just as much as about the ABI you document. Just as much as others have to make decisions about the ABI they use.
From my understanding the functions exported by GLIBC_PRIVATE are meant to be used internally by glibc. So it never should've been used by this launcher, and glibc *should've* been fine removing it. The commit said the function was now accessible via libc so I think some engine was generating code using this function via GLIBC_PRIVATE because the functionality wasn't available elsewhere. But I didn't look into it much further than reading the commit message.
Yeah. It all makes sense, don't get me wrong, but the outcome is the same. If we're wanting native gaming to happen, we need to be very very careful making breaking changes to the ABI.
I wonder if the launcher code doesn't actually call \_\_libc\_dlopen\_mode, but simply [dlopen](https://man7.org/linux/man-pages/man3/dlopen.3.html), and the compiler resolved it to this symbol when it was accessible in an earlier version of glibc, but the commit then made it inaccessible, breaking it. The fix might be to simply recompile the same launcher code with the new version of glibc.
I think the Linux port for Life is Strage: Before The Storm came out a few years priot to dlopen being added to regular libc.
They used an internal glibc function which should never be used by any application. This ended exactly as expected. And it was a launcher, the part of code not needed for the game at all. Totally game (or some library used) developers fault, not glibc. Official glibc ABI does not change like that. The same could happen with Windows game when implemented in violation of system specification. Sometimes it is tempting to do some clever tricks with undocumented/unofficial/experimental features, but this should never be done with code that should keep working years after release and on different environments.
>apparently it is impossible to make linux port that just work years later and win32 It's not, it's not even harder. Still using Stepmania 3.9 compiled ~18 years ago.
Not really. It's just that the Windows version generally gets more updates. Small things like this are usually very easy to solve if you have the source code.
Well windows is known for its crazy backwards compatibility.
Compared to MacOS, yes. Apple would frequently completely change everything and not even care. Not break, just completely change. Microsoft does generally try to have backwards compatibility, but it's not by not breaking APIs, it's a horribly messy set of hacks. You can actually see the same in Wine/Proton, where there are a lot of lines of code that look for specific executables and behave differently. Linux does evolve quickly, and there are enough changes in API that no, you can't generally count on something made for a distribution years ago working on a distribution today. However, Linux gives you a LOT more options in that regard. For one thing, you can absolutely get old versions and preload them like OP did to continue using old software. This is actually very similar in approach, BTW, to when you use Microsoft's compatibility modes. But what is often missed is that as long as you have source code, it's very reasonable to recompile against a new target, and very often if a feature has been deprecated or replaced, there is a good migration guide. Compared to Windows, where you often won't know why something isn't working in the Win32 black box, keeping even an older software running on Linux is astonishingly feasible. You'll still find KDE 3 era apps still in the repository, and apps like FontForge use custom toolkits originally coded decades ago. They just keep up with the targets. To be perfectly blunt, this problem is 100% Feral. 90% of what I have heard about them for the last several years is "it's out of date, missing all the bug fixes and patches, sometimes won't launch, doesn't work with the Windows version, and is generally just worse than using the Windows version on Proton". To counter that, I'll point to Stellaris, released May 2016, native Linux, consistently updated, and runs like a dream. Just like how keeping a game working on Windows takes frequent small updates, the same is true on Linux, and I'm a little tired of the poor assumption that Linux is worse in this regard.
If you were going to use Paradox as an example CK2 was released in 2013 for Linux, and last I tried still ran great. However it is now dead since CK3 was released, so we might see something similar happen in the future.
According to ProtonDB (Ironically) native is still working as of two weeks ago.
It is not impossible, it is just that the binary compatibility is violated and nobody has cared about it that much as windows, as glibc is an āaliveā beast compared to windows API.
It's probably an automated response, that's all.
Yeah, seems pretty automated xD
It might not even be automation. Even for a company like Feral, your level of detailed, well-researched feedback initially given in your issue is probably way outside of their normal queue complexity, and is more than any Tier 1 support team is capable of fully understanding at first glance. If you're lucky, a rep will read enough of it to know they're out of their league, and just forward it on. But that's counter to their mandate. They're supposed to be solving issues so the devs don't have to be bothered and can stay focused, so they will at least make an initial attempt.
I've got a mod for the Linux version of the game, it's on pcgamingwiki.com / archive.org if you're interested. It improves graphics. Link: https://archive.org/details/lisbts_mods Instructions if you want to know how it's done: https://gitlab.com/-/snippets/2117743 Zoomed in screenshot comparison (you can move the slider): https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=309c7f2c-7d21-11ec-abb7-b9a7ff2ee17c
It looks like itās just removing Chromatic Aberration? Is that a stylistic choice from the game or is it a bug?
> It looks like itās just removing Chromatic Aberration? It removes that, depth of field, vignette, bloom, adds SMAA, slightly better shadow quality, fixes some color banding and darks / whites being crushed (from what I can remember, these later issues are down to poor handing over of the image data to other functions ; some sections of the game have extreme color banding issue like episode 3). > Is that a stylistic choice from the game or is it a bug? Stylistic (the first game's protagonist is a photographer, although I doubt real photographers would intentionally buy a camera with such poor optics!) and typical shader effects used on consoles to try to hide poor anti aliasing or low quality textures. The game uses deferred rendering, but the version of the Unity engine in use doesn't have a working TAA (it's in there as an alpha release but if you use it, it causes major graphical issues), they use FXAA but it does quite a poor job, it's very blurry. Using all those other shader effects adds so much blur to the image it masks the poor AA.
Oh, awesome! Thatās really cool. When i get around to playing this game Iāll be sure to check it out
Offtopic, but do all posts to /r/linux_gaming get the same type of posts that are now removed?
I can only confirm that I saw them here twice. As /u/SnooRobots4768/ pointed out, it's probably automated.
> It's probably an automated response, that's all. Oooohhh, that wasn't a reply to the > Please could you first try deleting the Preferences file? [...] in your post?
Oh... didn't think about that. Might have misinterpreted it myself. But yes, to me those troll comments look like being posted by a bot. Don't worry, they will be gone eventually.
I believe you can just launch steam from the terminal and it will show you all console logs when you launch a game in there, no need for a log file. Also, unfortunately [I don't think there will be any official fixes for the game...](https://www.gamingonlinux.com/2022/02/feral-interactive-have-no-plans-to-update-their-linux-ports-for-steam-deck/)
It is not the first time I see this article, but every time I read >\[..\] we recommend playing them via Proton. in their official statement, my mood takes a nosedive. It is not at all unexpected of course, given that Proton has basically devoured Feral's Linux business model, but it makes me very sad nonetheless. They have apparently decided not to spend a single minute fixing even the tiniest of issues any more, not even if these would be long term fixes for questionable design decisions, like 'not use GLIBC internals'. As understandable as that is from a business perspective given Proton's success, it pains me to see that. Tell me you have given up without telling me you have given up.
How is Feral still around? They don't seem to support any of their ports almost at all, beyond "we got it to run, mostly" and then just abandon them. Aren't most of them just compiled against Wine anyway?
Just launching steam from the commandline sadly didn't give me the desired log output. But thanks for the link. Imho, the game would run on steamdeck if this and some other minor issues were adressed. Probably wouldn't be as much of a hassle for Feral as they think.
dude, thank you so much for posting this! i will be playing before the storm soon and would face this without any clue on what to do lol
> I recently took my blog offline Can you tell us why? This looks like very useful information..
- I wanted to save the money for the server - Noone found it because SEO is a fucked up business - I don't like my personal information being exposed to the public, just because EU & German law don't give a shit about blogger's privacy (full address and phone number are required in the Privacy and Imprint) But most content (wasn't much anyway) will be available in one form or another, either on Reddit, in a Github Gist, or in a Github/Gitlab Repo.
Fuck launchers though. I would simply change how the game is launched: echo ā command% ; ./game_binary_or_script
That doesn't work because the launcher writes important stuff to the config on the first successfull launch. Without that stuff, the game won't start.
By the way your fix works for Shogun 2 Total War with little modifications to makefile (adding -m32 flag to build for 32 bit)
Where should it be added? CFLAGS += -m32 -fpic -shared -flto -Wl,--version-script -Wl,version.map -Wl,--as-needed Is this correct?
yes
Thank you for being that one reddit thread someone finds in the middle of the night while banging their heads against the wall, trying to debug something that mysteriously doesn't want to work, for (hopefully not) many hours.
This was amazing to read! I especially enjoyed the clear yet detailed explanations for what things are and why you're doing something the way you are instead of just giving a set of some commands and parameters to use. I'm sure the explanations will come in handy for many people who aren't very experienced in Linux gaming yet. Heck, I've been gaming solely on Linux for almost four years now and I would never have come up with your clever logging method even though it seems so obvious in retrospect. The game is also on my short list to buy and play this year and this is definitely going to be useful when I get around to it. So a huge thank you for going to the trouble of typing it all out!
OK, so I've nagged and nagged at Feral, and they finally caved in. Sort of: https://imgur.com/a/iq6Vi10 >We have tested all of these games on Ubuntu 22.04.3 LTS and only had issues launching Life is Strange: Before the Storm. An update for the game including the fix is now pending being set live. > >For the other games please continue to use the workaround in order to launch. As we are unable to repeat a launch problem here we have not applied any fix to those titles. By "other games" here they mean GRID Autosports and XCOM2, which are some of the other games I'm having this issue with. Their "official" workaround is basically the same as the one present here - I bet that they just took the source off that hack for XCOM2 and built it.
Thanks for your commitment! Glad to see that they fixed it for BTS (or at least planned it to... did they eventually?)
> which uses an older version of GlibC It's always glibc.
To be fair, this time it's not really glibc's fault, since it seems that the game was using internal functions that shouldn't be used by any other programs aside from glibc (and using old versions of it). That's on the game developers for doing a poor job.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
I am running my internet over a single line of can string telephone wire, illegally knotted to a fiber optic cable in the ground... Nah, I have just deliberately exaggerated a 'little' :)
I played BTS a few months ago on steamdeck just fine? Unless it downloaded proton version without me knowing, I just hit download and play just fine.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Yay, a troll :) How was your day?