> The elf binaries ran essentially flawlessly on my linux machine (although my machine was under powered for the game.)
> Sadly we never released the game on Linux to the public.
That's an improvement over not having a Linux port at all, as it reduces the investment needed to publish the game to Linux eventually. Once the Linux gaming market is big enough, studios might consider to release the game.
I'm not sure that's much of a distinction between not available and nearly available. Rumour is, WoW had an internal linux client for years, and that didn't help gamers.
That said, I wonder if being low-key not released multiplatform might actually mean there's likely less compatibility issues when playing with wine/proton.
The post you are responding to was pointing that this client actually existed - if I had to guess probably to allow people working on the server to test it directly on their machine - but was never released.
Absolutely, but my point is that even in that case, it would make more sense to run it under Wine anyway, instead of maintaining an entire build for a platform that is not officially supported.
I run Linux, and play games, but all in all, I strongly believe that Wine ports are the only realistic, less-worse, alternative. I'm not the only one - Carmack expressed the same (although, to be fair, I've never read other high-profile devs discussing this idea).
> We eventually laid out a guide with known good versions of Linux and graphics drivers, but it didn't matter. Part of the allure of Linux is the customizability, so few actually stuck to it, and generally wanted to run the game on older hardware we didn't support.
In order for Linux games production to be economically viable, there should be a Linux gaming standard, but because of the Linux culture, there will never be (there's nothing wrong; it's just its nature). Even if somebody came up with a gaming standard... xkcd explains what would happen: https://www.explainxkcd.com/wiki/index.php/927:_Standards.
I'm not considering adhoc Linux gaming distributions like SteamOS, as they would have to be treated as an independently installed, separate, operating system.
Same here, and I've also noticed the library churn is a problem: Heroes of Might and Magic 3 and Neverwinter Nights both have had official Linux ports/releases, and neither of them run on modern Linux distro's because of library incompatibilities (in the case of NWN, it's because of libSDL, don't remember the issue with HoMM3).
Even my recent purchases on GOG where there's plenty of native Linux to be found, I usually download the Windows version because WINE is a more stable platform in the long run, in my experience.
The latest version of Neverwinter Nights Enhanced runs without issue on Linux Mint 20.
The Beamdog Client no longer seems to work (pango lib issue), but GOG installs just fine. I like Beamdog and appreciate their ongoing support for Linux and have in turn purchased NWN gift keys for many people, but man - fix the Linux client please.
(Beamdog, feel free to contact me and I'll fix the broken client for free - seriously).
To be honest wine is so awesome it makes games run better even on Windows.
On another computer I had, with the supremely buggy nVidia Optimus, SimCity 4 and Arcanum: Of Steamworks and Magick Obscura both worked correctly only with Wine DLLs on their folder, preventing them from using Windows normal APIs.
HoMM3 has an open source port, and NWN not because of LibSDL, which still works, but maybe with GL functions, something solveable with an env var. If it's OSS related, wrappers exist.
There is the steam linux environment [1] which is pretty standard for native linux builds on steam. And that works independently of the distribution steam is actually installed on.
I think it should be possible to use it without steam too..
The libs in the steam-runtime are often times very old. The newest compiler for building inside the runtime seems to be gcc 5. I understand the need for stability, but why isn't this stuff updated from time to time?
because you would need multiple runtime versions and games would need to target a specific runtime version.
because if you don't keep your game up to date, it would not run. in windows you basically can run games for way longer because libraries are way more binary compatible. for running webservers/cloud whatever a breakage doesn't hurt and removes old crud, but sometimes the old crud is used in xyz in a way that nobody tought and without it the game would crash, that's why you would need to target a specific runtime.
the same thing more or less did windows up to 7 relativ well, via the version selection. unfortunatly windows 10 broke some games even with the version selection.
Games can have their dependencies shipped with them with or without static linking. They aren't transferring data to another game that has to line up exactly.
CG programs and renderers need to have subdivision surface data be the same and image filtering be the same. They may be able to architect their way around standard library versions, but games don't need this same treatment because they stand alone.
> because you would need multiple runtime versions and games would need to target a specific runtime version.
Yes. Steam already supports multiple Proton runtimes, why not multiple Steam runtimes as well? With the latter, native Linux games could say in their metadata which one they need and the user wouldn't even notice.
> And that works independently of the distribution steam is actually installed on
Not entirely, it still relies on some system libraries, and you will see there are times where games do not run on Arch despite using the steam runtime. It is known.
> auto reported crashes and support tickets (most gfx driver related)
I wonder if open-sourcing the game would see those same support tickets come in with patches.
Part of linux has always been about patching it up yourself. Rather than being a time sink for the developer, these linux bugs could actually be a way to crowdsource code improvements.
I know there are intellectual property concerns that prevent open-sourcing commercial products, but maybe there's some sort of hybrid solution to be found.
I hate that Linux philosophy for a daily driver. I remember being age 16, 17,18,19 23,26, and 27 and being told to figure it out. Every time I'm vastly more fluent and the community is just as unhelpful.
There's nothing intuitive about computers, a human came up with the rules. The negativity is cancerous.
Wine has a non zero overhead compared to Linux or Windows. Maybe one could come up with a mix of the Win32 API and Linux calling conventions? IDK. Or design something from scratch entirely, but then you have to write and maintain a translation layer like Wine for the rest of time :). Ideally one would take Wine and remove the overhead causing parts but keep most of it intact.
If the Windows program uses the Vulkan API, I imagine the Wine layer wouldn't be doing much work, would it? My guess is that the function-call conversion doesn't cost much on modern CPUs.
It's curious that Wine outperforms Windows on some CPU-intensive tasks, but is far slower for certain others. The article just gives the numbers, but doesn't give a deep analysis. Perhaps cache issues?
Most Android games could be easily ported to GNU/Linux, that just doesn't happen because studios don't see any commercial value in doing so, versus the development costs of supporting yet another platform.
I'm doubtful about this. Even though Android uses the Linux kernel, its userspace is completely different; There isn't much overlap in the APIs you can use on Android vs ones you can use on desktop Linux, besides a few things like openGL and syscalls.
> Sadly we never released the game on Linux to the public.
That's an improvement over not having a Linux port at all, as it reduces the investment needed to publish the game to Linux eventually. Once the Linux gaming market is big enough, studios might consider to release the game.