Patreon Logo Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone. Just good, fresh content! Alternatively, you can donate through PayPal Logo PayPal. You can also buy games using our partner links for GOG and Humble Store.
Latest Comments by appetrosyan
Editorial - Linux Gaming's Ticking Clock
25 May 2020 at 5:11 pm UTC Likes: 1

I would like to add that not all games are created equal. Some of them, like Alien: Isolation are installed, run and completed several times over. Right now Linux is a hard sell for en-mass installation because, as much-better-poets-than-me have remarked, we have no compelling reason to have people switch over and there are barriers. Proton and DXVK reduce the pressure to switch away from Linux but they don't create pressure to switch to it.

By design, there are very few programs that can be run on GNU Linux and only GNU Linux. That includes Games. A thing that would have driven mass adoption, could have been if a single-player Half Life 3 non-VR were released as a Linux exclusive. Valve are under no obligation to create a Windows build and a vote of confidence would have been to release, HL3 as a Linux exclusive. It won't happen, but mainly because the mass adoption of Linux and control over a platform that you can't lock-in, doesn't compensate for the lost sales that they would have had. It has nothing to do with Exclusives allegedly being incompatible with FOSS (they are the key part of CopyLeft, and by design the proper GPLv3 is exclusive to FOSS). In fact, we don't inspire much confidence to have them delay the launch of HL:Alyx until they have a working build for Linux.

Another reason to switch would have been privacy and security. Unfortunately, it almost never is a factor in people's minds. You can't make it one, because preaching doesn't work. You can convert a small number of people, but not more than that.

Viruses create a pressure to switch to Linux, but not as much as I hoped. People don't care about viruses. Some don't care enough to use a mitigation like Windows defender that they already have! Much less spend time and effort to get away from them. The only way this pressure gets stronger, is if Microsoft keeps on making blunders and creating security holes, that cause ransomware outbreaks. Otherwise, why bother?

The abundance of Professionally monopolistic software that doesn't and will not support GNU+Linux because of catch 22. That's a strong pressure and a dealbreaker for switching away from Linux to Windows. It's sometimes enough to make people switch away from Mac OS, which has way more things going for it than Linux.

Community fragmentation. No! I'm not referring to people writing weekend projects like an app to keep track of recipes. Nor am I referring to the overabundance of Desktop Environments. I'm referring to the fact that if you search for Linux.org, and ask to download, you'd be taken to a wall of text with no descriptions. If I'm totally honest, I'd just prune the list down to Ubuntu, Arch and parabola, clearly stating that Ubuntu's the gateway drug, Arch is the hard stuff, and Parabola is the hardcore fanatic dosage. Sadly, far too many distress are pushing their own agendas on Linux.org, to remove them from consideration. It wouldn't be fair, too. I personally like Gentoo.

Lack of standardisation. What is the de-factor standard VoIP communication protocol for Linux? Anyone? Mac OS - FaceTime, Windows - Skype. Everything that is standard came from Unix and no newer standards are better. Wayland is supposed to be one new standard, and its support is abysmal. Office Suite? Apple - Keynote, Pages and Cells, Windows - Word, PowerPoint and Excel. Linux? Well we have a zoo. Thankfully they all speak the same language. Unfortunately instead of speaking it like Americans, Australians and Brits, they speak it more like the Aztecs, the Russians and the Japanese...

The User experience and Desktop Bling are a good selling point. Just go to UnixPorn and you'll see many compelling reasons to switch to Linux. But... that's the UI, not the UX. The UX is: I created my coursework in FreeCad instead of AutoCad, and got an F, because my project Supervisor couldn't open it. It's that I'm at a command prompt and instead of using the familiar apt install, instead I have to use paceman -S. It's fine, it's easier to type, but I would install by default a wrapper script that dynamically resolved what you want to happen and told you what the command is. It has to be there by default!!! We lack these common interfaces that people need to rely on, if they want to eventually stop thinking and get doing. The flatpak is a major step in the right direction and the fact that RedHat is forcing it on everybody is actually a good thing. because then I have a reliable way of making things work cross platform. If only it were also, you know... GOOD.

The only real advantages, like technical superiority the security are sadly the things that are the toughest to sell. Until we fix this, Linux will always be at the mercy of Microsofts and the Googles. If we want to change adoption we need a Killer App. And unfortunately, every killer app spot is already taken...

Editorial - Linux Gaming's Ticking Clock
23 May 2020 at 4:31 pm UTC

Quoting: Linuxwarper
Quoting: appetrosyanI agree to an extent. There’s always a way to politely remind people that their work is not quite up to scratch, and death threats for a job however botched is never warranted. That does not mean that trust cannot be lost and that there are no objective markers of quality. My issue with this debacle is both the immaturity with which we have made a fool of ourselves, and the extent to which the entire community was gaslighted. VP, have learned a valuable lesson about quality of work. We have learned that telling people to kill themselves is a bad thing.
To add to that, I don't believe it's wrong for a developer to rely on Proton at this point in time. My reasoning for that is that for some games or genres Linux isn't that profitable, and thus it's not feasible to do extra work to provide native. The extra work could be used to make more content for windows game.

Streets of Rage [External Link] developers provided keys to Valve so they could make it work with Proton. Ideally I would like native, but I understand that's not feasible and therefor I don't have any ill will against developers who decide to forego native release for Proton one. Provided their reason for doing so is warranted.

But it's important than when developers decide to go for Proton that they do it the right way i.e working with Valve and Valve's recommendations for Proton. Furthermore developers could be kind and give back X amount of money back in form of Steam wallet if players have played their game through Proton on Linux after X hours of played or something like that.
A bit intractable, but I’m sure it’s with good intentions.

Editorial - Linux Gaming's Ticking Clock
23 May 2020 at 9:26 am UTC

Quoting: Guest
Quoting: appetrosyan
Quoting: musojon74EDIT. I know we don’t all do this. Sorry to sound ranting but this is a big issue. We are a small market share. Plus we make ourselves smaller by only buying drm free and avoiding steam. ( not that I disagree with the principle of that ). But it does affect sales. Then we vocally shout about this. Then we shout at people for bad poets. Like Virtual Programming. It’s less they trashed their reputation, more like f it why should we bother supporting people who just shout at us.
I don’t think this is baseless. In words of RMS, we’re sacrificing convenience for freedom.

Also, If Virtual Programming are turned off of writing Linux ports, it’s not necessarily a bad thing. I can imagine a whole slew of games that they could have ported just as badly. Now those games probably went to feral, or conceivably didn’t get ported at all, and now enjoy a nearly hassle-free experience through Proton. The policy off shutting down things that you don’t like has the effect of things that you don’t like not showing up.
VP improved the quality of their ports massively after the initial Witcher 2 debacle. There are quite a few games they did that ran really well - including Witcher 2 once it was patched up. And they did help with some driver issues in Mesa. If they'd managed to get through enough and invest in a Vulkan backend, they'd be pretty much where DXVK is now, except tailored to individual games and giving support for them.

Losing fglrx drivers was a good thing. Losing VP is not.
I agree to an extent. There’s always a way to politely remind people that their work is not quite up to scratch, and death threats for a job however botched is never warranted. That does not mean that trust cannot be lost and that there are no objective markers of quality. My issue with this debacle is both the immaturity with which we have made a fool of ourselves, and the extent to which the entire community was gaslighted. VP, have learned a valuable lesson about quality of work. We have learned that telling people to kill themselves is a bad thing.

Editorial - Linux Gaming's Ticking Clock
22 May 2020 at 11:19 pm UTC

Quoting: LinuxwarperNative ports aren't sustainable. Such releases are so volatile that you can't persuade someone to switch or stay on Linux. Even if we do get native releases, we have to wait much longer than Windows to play the games. With Proton, it's stable and we can play games from first few days they are launched. The reason Proton fails is because there are actors within the industry who's business is reliant on Proton's failure, and they will do things to stop it's momentum.

Linux gaming's opportunity to kick off depends on Proton's success and Vulkan adoption. Imagine Proton and Vulkan as two buddies stuck in a underground cave. Proton has made a straight, narrow and small line up to surface water which both Vulkan and Proton is sustained by. While Proton does that, Vulkan is digging a path up to the surface. If Proton dies, Vulkan will too. Their deaths will symbolize death of Linux gaming's growth.

I can't state it enough, native ports aren't sustainable in general. Despite many major games having Vulkan renderer (Doom, Red Dead, Cyberpunk, etc etc) publishers/developers won't release them on Linux. That is pure fact. And the only way to play these games are through Proton. And when games work on Linux, even if it's not native, people will switch and stay on Linux. Marketshare will grow and that will surely lead to developers and publishers deciding on a Linux port, especially if by that time Vulkan has become widely used in the industry.

That all is a ideal scenario though. Microsoft and other actors will surely do things that will hurt Proton or/and Vulkan.
Hopefully, we can reach critical adoption and every other proprietary application just becomes outmatched.

Editorial - Linux Gaming's Ticking Clock
22 May 2020 at 11:18 pm UTC

Quoting: musojon74EDIT. I know we don’t all do this. Sorry to sound ranting but this is a big issue. We are a small market share. Plus we make ourselves smaller by only buying drm free and avoiding steam. ( not that I disagree with the principle of that ). But it does affect sales. Then we vocally shout about this. Then we shout at people for bad poets. Like Virtual Programming. It’s less they trashed their reputation, more like f it why should we bother supporting people who just shout at us.
I don’t think this is baseless. In words of RMS, we’re sacrificing convenience for freedom.

Also, If Virtual Programming are turned off of writing Linux ports, it’s not necessarily a bad thing. I can imagine a whole slew of games that they could have ported just as badly. Now those games probably went to feral, or conceivably didn’t get ported at all, and now enjoy a nearly hassle-free experience through Proton. The policy off shutting down things that you don’t like has the effect of things that you don’t like not showing up.

Editorial - Linux Gaming's Ticking Clock
22 May 2020 at 11:04 pm UTC Likes: 1

Quoting: Alm888
Quoting: appetrosyanEven Feral interactive are usually taking a windows code base and add a few minor changes through SDL and only recently began making use of Vulkan. The biggest problem with all of these ports is that neither of them is open source, and you end up with a hard-coded out-dated binary. This is not the case with Proton.
That is definitely the case with Proton™. Only now on top of the closed-source Windows™ binary (unpredictably changing patch over patch) you have the imperfect WINE wrapper.
Quoting: appetrosyanI’ll give you an example of Witcher 2. It’s a native port in name only, written by Virtual Programming. To try and run this on a modern machine will have me searching forums to try and figure out which dynamic libraries it used to link against, the performance was bad when it was Wine with OpenGL, it just got worse in comparison. This is because no one went back and patched the executable to work on modern Linux machines.
Ah, I see what you've done here!

Nice try, but no. You are trying to sell the "Let's Abandon Native in Favor of Windows-as-a-Target-With-a-Wrapper" by presenting one (and only one!) extreme example ("Witcher 2") as some sort of common practice.
Not quite. I’m more of a “let’s not trust the developers not to abandon their software, when that’s everything that always happened to their games”. I believe that the games’ code should be FOSS’d like Id (the real one, before Carmack left) used to do. The sheer problem is, most games that run using DXVK enjoy much better performance than OpenGL, simply because, as Liam said, Vulkan is a generation or two ahead.

In lieu of arguing from principle, I’d say just try any native game, and the same game using Wine + DXVK. Odds are there will be a not insignificant amount of performance uplift. Not to mention that you wouldn’t need to hunt down age old libraries. A non exhaustive list of games includes Doom 3 (non BFG), Quake 4, Dungeons (1, 2, and to some extent 3), Quake 3 arena, Deus Ex: mankind divided, Overlord etc. Sometimes the difference is marginal, but it’s only temporary. For performance and the user experience to improve, either the translation layer or the game needs to be modified, and often developers abandoned their releases post launch, especially on such a small share of the market.

By doing this slap-in-the-face job of "porting" the game "Virtual Programming" has effectively trashed its reputation and now has no hope of returning to Linux business. As it should be, because instead of using "Witcher 2" as an excuse for not making Linux versions we must (and we do!) punish so-called "porters" for bad job. Granted, in case of "Witcher 2" CDPR also had its share of hate, and maybe just a little too much, but honestly, where was their Quality Control back then?
While I generally agree that the Virtual programming port is a bad one, I don’t think that we are in any position to punish. We are not faced with a choice of a good or a bad port, we are faced with a bad port and no port at all. I’d argue that if you want more native ports, you should be encouraging the last minute half-arsed ports that Virtual programming had been actually releasing.

What we need are actual "Day-1" native releases made with Linux in mind from the get-go (or by using Linux-friendly game engines), not some three-years-later "ports" (of games everyone else managed to forget already) with 30% less performance and most of effects disabled.
Couldn’t agree more. Preference for OpenSource engines and FOSS games like 0ad, Xonotic, OpenMW, Freespace 2 SCP, Godot, etc.

Quoting: appetrosyanI don’t see how it will improve with time, but I do see that using Wine + DXVK will get better and better.
And I see it gets so good that it stops working after a publisher adds "Denuvo AntiCheat" (or basically any anticheat for that matter) or uploads a patch breaking "Proton Compatibility". And all that with impunity because you on Proton™ was given no guarantees at all.
I’d be surprised if a native port would continue working if Denuvo Anti cheat was on the table. I don’t see a huge difference between this and Rocket League being pulled for completely arbitrary reasons. You don’t get guarantees either way, except with a native port, you’re expecting that the publisher in their benevolence spends time and effort to remove the anti-cheat. With proton, you can run DooM Eternal, because the codebase is continually updated.

I’m not sure if you planned to give me ammunition to support my point, but you should be really picky about your examples.

Quoting: appetrosyanThe trick here is that because you’re taking the control from the full binary and giving it to the Wine runtime, you are effectively making an openSource interpreter for a proprietary language. The developers only have to worry about making it work on Windows, and proton takes care of the rest. And I think that’s what Carmack meant in his age-old 2012 post about GOL. By making native ports with bad user experience we are only going to turn people off of running Linux.
And they will do just that!
Are you using Proton™? Not our problem! So long and thanks for your money![/quote]Funny. They could say the same thing about native ports. Fun fact, although every single ID game up to and including DooM 3 BFG, has a functional binary port (which is actually native), however, Bethesda in its wisdom has seen fit not to add the badge and officially support the binary releases. For them to murder the Proton they have to patch some sort of selective DRM that refuses to play in emulation, that was also hack-proof. I honestly think it would be cheaper to just pull all mention of all those games.

You see, you keep forgetting that you’re not actually buying anything. You’re given a temporary non-transferable license that can be revoked at any time, for any reason, despite you having paid. There’s no fundamental difference between them pulling Proton support because it’s not guaranteed and saying “well, we’re tired of supporting the Linux binary, so we’re killing it off”. You’re SOL either way, but unlike the latter case, there’s a huge chance that a game not working through proton can start working eventually.

Editorial - Linux Gaming's Ticking Clock
22 May 2020 at 5:03 pm UTC

Quoting: Purple Library Guy
Quoting: gradyvuckovicReading over everything you wrote Liam about the different platforms competing, I don't think there should be any doubt that the way every major player in this market is competing right now, is with a strategy of platform lockin.

It's the name of the game. Every platform wants exclusives, or a subscription model, or at the very least to lock players into their platform with huge libraries of games, or a sense of dependency on a particular feature set, or 'something'.
It's an interesting problem for sure. One thing that makes it a problem is that the nature of Linux and open source makes it very hard to use lockin tactics in the usual way. However, there are forms of "opening all the things" that could effectively become exclusive-like in practical terms.
For instance, people have mentioned in this thread the ability of Proton/Wine to run old Windows games better than Windows does. Boxtron might also be mentioned in this connection. This is presumably true not only of old Windows games, but old Windows software in general. And there is a ton of old Windows software. In the past, all the masses of little old Windows apps for lots of little tasks that people still rely on was a shackle holding people to the safe backwards compatibility of Windows. Now the ability to use all that stuff could become an exclusive feature of Linux. My dad has this genealogy program that won't run on newer Windows . . .

There's the "Open source isn't spying on you" feature. Linux probably already has most of the paranoids . . . but paranoids are plausibly a growth market what with the way the world is going. You're not paranoid if they really are out to get you . . .

Linux could extend its various attempts to make everything run on it. Get serious about running Android apps, for instance. The Linux advantage could be that whatever platform you want something from, Linux can get it for you.

One thing to keep in mind in terms of growing the Linux (gaming) desktop is that we're sort of piggybacked on all the other Linux use cases. Desktop Linux is still viable largely because server Linux, HPC Linux, embedded Linux, "tinkerer" Linux (like Raspberry Pi and stuff) and so on and so forth are all prosperous or dominant in their spheres. That gives us a big mass of development happening on the Linux kernel and various important, infrastructural Linux software, so the core OS keeps on being very competitive, not to say awesome. Plus it creates this pool of people who work with Linux for various reasons, and some of them start wanting to use it for their desktop and their gaming.
The corollary is that every time Linux gains ground in some other space, it gives desktop/gaming Linux a little boost. And in fact, any time any open source software gains ground, it gives desktop/gaming Linux a little boost because open source software virtually always at least runs well on Linux and often is closely associated with Linux even if technically cross-platform. So if Blender starts taking over its space, there will be more Linux workstations, more development for graphics-oriented Linux software, drivers and so on, and a few more Linux desktops.
So we need to watch out for, and feed, disruptive open source software in various fields.

Spoiler, click me
This relates to Windows dominance of the office space, and the growth in work from home seeming to have driven a growth in use of Linux desktops. Windows general desktop dominance would be reduced if they didn't control the office desktop. Apple's desktop niche would be way smaller if they didn't have such a footprint in the "creative" desktop. Linux needs to build its own niches and make inroads into those. This can be done.
I've said before that there's a tendency for open source software to dominate when it reaches a certain size. Open source software is hard to kill entirely, it can limp along as an also-ran for years and years in the shadow of big commercial offerings where a small closed competitor would go bankrupt and die. In that state it tends to have core features but be unpolished and missing things compared to the top closed source player/s. But sometimes something happens. Some key, energetic developers arrive, or some industry players decide this thing is needed and fund it, or some reform of how it's run makes it more high-profile and submission-friendly, or the people who have been plugging away for ages finally get the infrastructure how they want it and the fruits of their labour show up in big featureful releases. And development accelerates, excitement builds, user numbers grow, a "critical mass" is reached. Once this process begins, it feeds off itself--the better the features, the more users and developers, the more users and developers, the more features. At a certain market share, it becomes difficult for closed source to compete. And there's a new niche for open source, and riding on that a new niche for Linux.
So yeah, every time a piece of open source software hits critical mass and starts taking over some niche, it's ultimately a win for Linux gaming. We should be watching out for and helping such things.
Really well put. However I would argue that there’s a slight problem with the software utilisation. Most companies are using Microsoft because they can’t afford the downtime, the IT guy is very old fashioned and because they’ve already bought a subscription and want to make the best of it.

Editorial - Linux Gaming's Ticking Clock
22 May 2020 at 6:09 am UTC

Quoting: damarrinLinux is in pretty good shape, barring some snags for new users (e.g. the complete mess with snaps, flat packs, native packages and appimages).

What needs addressing and pronto is perception and market share. I think the only way for this to happen is millions into marketing, like what Apple did in the noughties. Idk who might be persuaded to put down the money. Maybe someone prominent in Linux with a proven advertising track record could start a crowdfunding campaign.
I’d say Bryan Lunduke, but he’ll probably pocket the money.

Editorial - Linux Gaming's Ticking Clock
22 May 2020 at 6:00 am UTC Likes: 2

I heard this speech a thousand times and will probably hear it again. There are very few truly native ports out there. Even Feral interactive are usually taking a windows code base and add a few minor changes through SDL and only recently began making use of Vulkan. The biggest problem with all of these ports is that neither of them is open source, and you end up with a hard-coded out-dated binary. This is not the case with Proton.

I’ll give you an example of Witcher 2. It’s a native port in name only, written by Virtual Programming. To try and run this on a modern machine will have me searching forums to try and figure out which dynamic libraries it used to link against, the performance was bad when it was Wine with OpenGL, it just got worse in comparison. This is because no one went back and patched the executable to work on modern Linux machines. I don’t see how it will improve with time, but I do see that using Wine + DXVK will get better and better.

The trick here is that because you’re taking the control from the full binary and giving it to the Wine runtime, you are effectively making an openSource interpreter for a proprietary language. The developers only have to worry about making it work on Windows, and proton takes care of the rest. And I think that’s what Carmack meant in his age-old 2012 post about GOL. By making native ports with bad user experience we are only going to turn people off of running Linux.

A word on stadia. While I do think that it may have some negligible beneficial impact, the best it can do is dethrone Windows. Google has a track record of loving Linux, and creating walled gardens of openSource tech that could not possibly be used with Linux. I expect Stadia to become a competitor to GNU/Linux, and far worse than Microsoft. At least with Microsoft we could have a technological edge... we can’t possibly win against a competitior that uses the same tech as you.

Serious Sam 4 announced for August, confirmed for Stadia (updated)
20 May 2020 at 8:41 pm UTC

I’m not usually on the side of Native > Proton, because in terms of end user experience the proton version has a clear advantage, but I mostly do that, because the people don’t have a truly native version: they have an SDL port of Code that was originally designed to run on Windows, and mostly tested on Windows, in other words a sub-par compile time emulation.

This is not the case. Croteam have a well-optimised Linux natives binary that has a very good Vulkan renderer, and very very few proprietary libs. I can forgive not having day one support (just barely), but I have a strong opinion about their company if they don’t have a Native build in a month or two.