I’m asking because I just bought Cronos: The New Dawn on Steam because it has a native Linux port. To be fair, I would have bought it at some point anyway but I got excited when I saw it had a Linux port. The game is missing features that the Windows version has, It runs horribly at any setting other than very low. I think they only bothered testing for the SteamDeck. But if that’s the case, why does it support FSR 4.0? To be fair, the Windows version doesn’t run amazing either if you enable ray tracing but it still performs way better than the Linux port. Why do devs keep doing this? I’ve bought many Linux games that have problems that the Windows versions don’t have. Why even make a port if you’re not going to bother testing or optimizing it?
You must log in or # to comment.
My partner has had a really bad time trying to run cronos. We thought it was initially Linux problems, it’s the first game on her new rig. Turns out the game just has those problems on windows
I know this is gonna dig deep, but consider this…
Linux just barely broke 3% share. As a company, whose goal is to make money, would you focus on what 97% of your base uses, or the 3%?
Further more, the company needs to spend QC resources for 1-2 versions of Windows, vs the multitude of Linux distros, but let’s say you can get a passable port, may not be the best but for minimal effort you can sell to a handful of that 3%, the business thinks “why not?”
In the grand scheme of things, native Linix ports is still low on the priority list for a company focused on making money
A lot of the “native ports” are done by a third party studio, and they don’t maintain it. Because of this, many games perform better through proton than natively.
Also save data is not shared between the versions, so if you’ve already sunk a lot of time into playing the buggy native port, switching to proton requires you to start over.
Ya, and with Proton working so well, I’d rather focus on Windows, then at most work with Valve on making sure the game runs well with Proton. Way less work.
From the sole developer responsible for Factorio’s Linux-native port: https://www.factorio.com/blog/post/fff-408
“Why don’t most games support macOS and Linux?” is a sentiment I often see echoed across the internet. Supporting a new platform is a lot more than just changing some flags and hitting compile. Windows, macOS, Linux, and the Nintendo Switch all use different compilers, different implementations of the C++ standard library, and have different implementation quirks, bugs, and features. You need to set up CI for the new platform, expand your build system to support the new compiler(s) and architecture(s), and have at least one person on the team that cares enough about the platform to actively maintain it. If you are a video game, you will likely need to add support for another graphics backend (Vulkan or OpenGL) as well, since DirectX is Windows-exclusive.
Many developers will take one look at the Windows market share and decide that it is not worth the trouble to support other platforms. Also, with the meteoric rise of the Steam Deck and Proton, it is easier than ever for game developers to ignore Linux support because Valve does some black magic that lets their game run anyway.
The list of Linux-first games is so short it’s not even a factor. It’s very difficult to justify the additional effort of implementing a platform that serves exclusively the playerbase with a ~3% market share, especially when a different method exists to serve that same playerbase that works just as well and also serves the 90%+ with no additional effort.
The article I linked also contains an explanation as to why GNOME’s decision to drop server-side decorations is fucking stupid.
Also separate from my long response, thanks for sharing that link. Very interesting read and the GNOME window decoration issue is rediculous.
For me, I’m sorry to say, GNOME is the epitome of asshole design. This one of many examples of its rigid design philosophy having negative consequences for users and devs. And devs are protecting GNOME from its own users bad experiences because the user blames the game for not conforming, not the DE for being rediculous.
It’s a none issue these days because toolkits and engines are gonna implement their own decorations anyways and for everyone else there’s libdecor.
It really does feel like Linux desktop environments like GNOME and Cinnamon got stuck in 2009 and never evolved past that. Even the community feels reluctant to adopt tried-and-true design elements of modern desktop environments, like removing the title bar so users can take advantage of that extra space at the top. “Wouldn’t that cause issues?” Uh, no? It never has. It’s time to innovate, please.
You do know the reason GNOME is pushing CSDs is to get rid of titlebars right?
No, I wouldn’t know that because it’s not implemented and I don’t have a distro installed that uses it anymore.
We’re not talking about the same thing. GNOME did get rid of titlebars, most core applications use sidebars and the rest use headerbars - which are better integrated titlebars. I suggest reading the article.
Worth saying the 3% market share is very new, and previously the share has been way way below this. At 3% that is millions of users but even that is hard to justify a linux release; many games dont even get MacOS versions even now and it has higher desktop share.
The other problem for linux is version control - libraries are different across distros of different ages, and also constantly update. If you build software on a dependency and it changes in a few years, your game may break. As bad as windows is, when games are distributed a lot of the dependencies are distributed with the game as DLLs and installers for Microsoft tools. But for linux you previously could not guarentee the same version of the same dependency will be available on two distros still actively supported.
It can be surprisingly hard to get old Linux software to run on new Linux distros. People are not generally aware of this as generally its old windows and dos games that people try to get working (so wine or dosbox are used), not old Linux software like Open Office from 2005 or an old version of Firefox. Most linux software continually evolves or its niche and just stops working (unless youre willing to go back and compile from source, and that can get nightmarish if it doesnt compile)
Proton is part of the solution but developing “for” proton is not efficient long term. It is great for enabling windows games to work on linux, but linux native games would be more optimal. We’re just lucky we’re now in a time where there is a lot of CPU and GPU resource available to support the overhead and windows is also so bloated making linux + proton comparatively better.
I suspect Flatpak may be another part of the solution - Flatpak can essentially be a way of ensuring a game can have a fixed set of dependencies which install on any Linux and should just work. Its not that far off the windows model of packaging DLLs, but is much cleaner and contained.
Nix is another potential approach to this.
But developing for Linux wouldn’t take off until the market share is substantially higher. The SteamDeck and tge rumours Steam console may help with that, but for now I think devs relying on Proton makes sense.
The market share is never a precise number because not everybody is asked to do the hardware survey, and not everybody who is asked does. But the Linux userbase is small enough that “~3%” is in the ballpark.
Version control of dependencies is not as difficult as it seems. Unix systems can easily implement bundled dependencies like Windows does, even without sandboxed or monolithic packaging formats. The important thing is to tell the dynamic linker (
ld.soin Linux’s case) where to look for the library files, similar to howPATHis used to locate executables. This is similar to how containerization works to a lesser extent, and the Steam client actually does this by loading its own.sofiles from~/.local/share/Steam/.... I’m sure there are additional challenges, my knowledge is superficial and approximate at best.But the point still stands: in most cases, Linux-native ports are simply not worth the effort, either because of limited resources in small teams, or because of profits in large studios. BG3 and Factorio are definite outliers.
This is the exact thing I was telling people when proton came out. Sure it’s great that we can pay Windows games on Linux now but it’s just creating a new problem where developers literally have NO REASON to create native Linux ports. Plus, while proton is great, it’s not perfect. If a game doesn’t work correctly through proton the developer aren’t likely to care that much so fixing it will fall to Valve or the community. I’ve also heard of games getting updates which break or degrade proton compatibility. The developer isn’t likely to care about that situation either.
Because it costs money to maintain that most indie studios don’t have given the small target audience. I simply always use Proton, even if a native version exists.
Yeah I get that and I’m not disagreeing. But why port it at all, that being the case?
It might also be a single dev who pushed for it. With only a 1-3% market share, the company is unlikely to push resources at it. That 1 dev getting any working version out is a win in many ways.
Also, most Linux users are a lot better trained at reporting bugs. Most of the time, this is a good thing, letting them get fixed in FOSS development setups. Unfortunately, in gaming, it ends up making Linux look a buggy mess. When 60% of your big reports come from 0.5% of your users, companies can panic. Even if the same bugs exist in windows, just no one bothers to report them.
I’d guess because it’s an option in whatever they’re using to develop the game, doesn’t mean they’ve manually tested it much if it at all though.
It’s gonna be different case by case, but my best guess would be it starts as wanting to please the community, then realising Linux users get weird errors they never hear about from Windows users and then deciding that all 5 Linux users are not worth it if the issue doesn’t concern majority (Windows) users.
As for missing features, usually it happens because they use some Windows-native feature (like direct DirectX calls) which saves them implementing workarounds for their engine. And porting to some Linux api is delayed indefinitely for the same reasons as bug fixes: not large enough user base.
Linux gamers often say stuff like “it’s literally one toggle in [insert game engine here]” but that’s never the case. Doesn’t mean new devs don’t fall for it.
IMO we should fuck native Linux builds - game engines are complex and messy beasts, building on one platform and testing on Proton is the best for everyone, IMO.
Simon the Sorcerer Origins was recently released and their Linux version didn’t even run. Their run script contained just two lines and both of them were plain wrong. And after I fixed them the controller didn’t work.
It takes a lot of effort for little money.
I have a question (an honest one, not implying anything). Given that most games work perfectly on Proton, why does a Linux port excite you?
It can be beneficial in terms of performance if done right. The native Linux build of Baldur’s Gate 3 runs considerably better than the Windows version via Proton, even though the Proton version already runs better than it runs on Windows natively.
Good question. It means to me that developers thought that Linux as a platform was worth targeting. One could conclude, the more Linux ports we see, then more people must be using Linux. It’s my dream for us not to be treated as second class citizens where computer operating systems are concerned.
It’s a baby step thing. They want to develop for Linux but so far it’s about 3% of steam users that use it. So when a studio does its testing/optimizing they focus on the platform their player base is using most.
Obviously there’s a negative feedback loop here. Players avoid Linux because of issues which causes devs to neglect it because of player numbers which causes issues in the game…
Steam is pushing Linux currently but it’s hard to overcome the dominant position windows and consoles have. We’ll get there though.
On paper, a Linux version of a game would perform slightly better, because they wouldn’t have to use Windows system calls for synchronization and disk I/O.
This seems to be true for the games in my Steam library that have good Linux versions, though I can’t comment on the performance of bad ones because obviously I play those through Proton.
Unreal Engine’s Linux builds are very neglected compared to Windows. Windows gets DX12 which is the main rendering API for the engine, Vulkan (which the native Linux version uses, also available on Windows) is a complete after-thought unless you’re on Android where it is the main target.
Main Linux target for UE is Red Hat Enterprise Linux for movie CGI. The “we want open platforms” company don’t care about Linux gaming.
Specifically hates linux actually, Tim Sweeny is a huge Windows stan
Because they live in a fantasy world where optimizing a game for Windows and pouring countless of hours of QA into the Windows version makes a merely cross-compiled Linux version magically great as well because “PC is PC, right?”
Windows dominated desktop development for years, and Macs did the same in the creative world. So a lot of developers naturally know those systems best. Linux has always had the problem of fragmentation, different distros and different library versions all pulling in slightly different directions, which makes it harder to target reliably. That’s why things like the Steam Deck or Ubuntu LTS matter so much, because they give developers a stable baseline instead of chasing down tickets caused by someone building with the wrong version.
Tools like containers and Flatpak have improved the situation, but the underlying complexity is still there. When a studio doesn’t have the time, budget or experience to handle that, the Linux port is usually where the cracks show. The ones that tend to get it right are teams with stronger engineering depth, which is why you often see the better native ports coming from studios behind RPGs and sims where crossplatform work is already part of their pipeline.
IMO: additional CD/CI pipeline and according QA, paired with the technological regression we’ve seen in real time graphics over the past few years and videogames being developed in sweatshops with a carbon-nanofibre budget, while ads get all the budget is a poor foundation in general.
Why commit to anything more than the bare minimum, when you need to desperately try to reach that while the circumstances are against you?
It’s not devs in general. Bloober is notorious for releasing poorly optimized games. They probably run terribly on windows too.
That hasn’t been my experience. I’ve played most of their horror games. I haven’t played The Medium yet but I will soon. Their games generally run pretty well for me. I will admit, I am a fan boy though. They are one of my favorite game developers.
The question is backwards: why are you not natively developing games for linux distros to see all the pitfalls developers deal with on a shoestring budget?
Easy to ask a question you do not traverse, harder to pave an easier road for everyone else.I feel like I never use native Linux versions. The exception thus far has been Two-Point Museum and Vintage Story. There are other games that have native Linux versions, Necesse and Mind Over Magic come to mind, but in my experience the Linux ports are never that stable and have spontaneous crashes that can be avoided altogether by running in Proton.
deleted by creator
