Valve Is Working on Another Extension to Help in Direct3D-over-Vulkan(phoronix.com)
phoronix.com
Valve Is Working on Another Extension to Help in Direct3D-over-Vulkan
https://www.phoronix.com/scan.php?page=news_item&px=VK_VALVE_mutable_descriptor
307 comments
I hate to be that person but I've had no issues with the Steam client on Linux, and I've used it full time for years. Including more "advanced" features like in home streaming.
The nature of Linux platform problems is that they crop up for specific combinations of hardware and software. The biggest thing that Microsoft has over the open source community is the money to pay developers to bulldoze the combinatoric jungle that is compatibility. That, and the platform clout to get vendors to make their stuff work.
> the money to pay developers to bulldoze the combinatoric jungle that is compatibility
For hardware support, the biggest thing is stable kernel ABI for drivers.
> the combinatoric jungle that is compatibility
Windows doesn't have combinatoric jungle. With their amount of supported hardware, combinatoric jungle would be prohibitively expensive even for Microsoft.
Instead, Windows has well-specified ABIs the drivers must conform to. And a set of development tools to verify that's the case, both static like code analysis, and runtime like driver verifier.
For hardware support, the biggest thing is stable kernel ABI for drivers.
> the combinatoric jungle that is compatibility
Windows doesn't have combinatoric jungle. With their amount of supported hardware, combinatoric jungle would be prohibitively expensive even for Microsoft.
Instead, Windows has well-specified ABIs the drivers must conform to. And a set of development tools to verify that's the case, both static like code analysis, and runtime like driver verifier.
Plus reasonably good documentation.
My experience is that Windows is just as bad. HiDPI doesn't work right unless the developer goes out of their way to support it. Random combinations of software hard-crash the entire OS. (My current easily-reproducible example? If you use PowerToys to tile windows, and a tiling operation happens concurrently with a DPI-resize operation, the computer blue screens! Fun!)
I was an early adopter of Linux and used a lot of weird hardware with it, and no combination of dragging windows ever caused the computer to reboot. What annoyed me most about Linux is how I got used to the brokenness, and it got fixed without being able to replicate the brokenness I was used to. For example, circa 2012 I got an early 4K monitor. It was implemented as two scalers connected to one panel, with both scalers connected to the same Displayport interface. Basically, it appeared to the computer as two separate and totally unrelated monitors, but was of course a single monitor. I could not for the life of me get Linux to treat both panels as a single monitor. But I used multiple monitors in the very early days of Linux, before XRandR, and I could never get it to treat my two monitors as separate devices -- windows would just pop up right in the gap between two monitors; X had no awareness of where the boundary was. I longed for that behavior, but the option was simply removed... because who would ever want that brokenness? (I did end up getting it working. There was a bug in the Nvidia driver that allowed you to turn on two options that caused all XRandR related functionality to silently break, and then my one monitor appeared as one monitor to the OS. Of course, even though my graphics card had 3 more video ports on the back, I could never connect another monitor. And I was always worried that a driver update would fix the multiple-interacting-bugs. But it never did! Or at least I replaced the monitor before it became a problem for me.)
I was an early adopter of Linux and used a lot of weird hardware with it, and no combination of dragging windows ever caused the computer to reboot. What annoyed me most about Linux is how I got used to the brokenness, and it got fixed without being able to replicate the brokenness I was used to. For example, circa 2012 I got an early 4K monitor. It was implemented as two scalers connected to one panel, with both scalers connected to the same Displayport interface. Basically, it appeared to the computer as two separate and totally unrelated monitors, but was of course a single monitor. I could not for the life of me get Linux to treat both panels as a single monitor. But I used multiple monitors in the very early days of Linux, before XRandR, and I could never get it to treat my two monitors as separate devices -- windows would just pop up right in the gap between two monitors; X had no awareness of where the boundary was. I longed for that behavior, but the option was simply removed... because who would ever want that brokenness? (I did end up getting it working. There was a bug in the Nvidia driver that allowed you to turn on two options that caused all XRandR related functionality to silently break, and then my one monitor appeared as one monitor to the OS. Of course, even though my graphics card had 3 more video ports on the back, I could never connect another monitor. And I was always worried that a driver update would fix the multiple-interacting-bugs. But it never did! Or at least I replaced the monitor before it became a problem for me.)
I'm not sure that applies here. Steam specifically ships it's own version of libraries for compatibility between different distributions.
of course it applies, they have less resources to support more systems than Microsoft do to support one system, this will be reflected in compatibility
Unless Steam somehow operates directly with hardware, I don't see how that could happen. They ship their own runtime, with pinned versions of libraries Steam depends on. As far as I know it should work just fine on any Linux system (which is my experience running it on 3 different machines on multiple different distributions over the years).
The in home streaming has been a god send for this pandemic and having a new baby. Baby doesn't like sitting at the computer desk, so taking my handheld and using the home streaming I can play Slay the Spire anywhere around the house hosted by my linux machine. Works great!
I have only had getting the steam client to launch, and only after a fresh install. This was mainly on OpenSUSE a few years ago; I could get it working maybe 2/3 times after a fresh install, depending on whether I installed all the hacks in the correct order. Once it started up, I never had problems booting it again.
Do you have a HiDPI display? Do you use screen scaling?
There's an open bug on their issue tracker with many more suffering from their lack of support. If you you don't use screen scaling, you might not notice it.
Native notifications are simply not implemented, so I guess you merely just haven't noticed that one.
There's an open bug on their issue tracker with many more suffering from their lack of support. If you you don't use screen scaling, you might not notice it.
Native notifications are simply not implemented, so I guess you merely just haven't noticed that one.
I do not. What do you mean by native notifications? Steam has always had their own notifications, and those work for me as far as I can tell.
> no hidpi support
It's been added quite late, and who knows why it's off by default, but there is a checkbox now in Settings -> Interface called "Enlarge text and icons based on monitor size".
Works well here.
It's been added quite late, and who knows why it's off by default, but there is a checkbox now in Settings -> Interface called "Enlarge text and icons based on monitor size".
Works well here.
Does not work for me neither on gnome not on kde and I have to explicitly add gtk_gdi_scalibg to run arguments. Also no fractional scaling, lol.
I'm using it with GNOME 3.36 (Ubuntu 20.04). With 200% scaling set in the Display settings GUI.
Yes, I understand, it might work for you. Not sure if you expect that sharing this would magically make it work for me, the fact is that my personal experience shows it does not work in two entirely different linux distributives.
I'm saying it can and should work. And that it's possible for you to discover a configuration on your machine that would make it work.
And if it's still a no go, you can file a bug report (which you wouldn't be able to do, as such, if there were no such feature at all).
And if it's still a no go, you can file a bug report (which you wouldn't be able to do, as such, if there were no such feature at all).
[deleted]
That only works if you're running on HiDPI with no screen scaling -- which will just make everything else look tiny (though Steam would look fine).
Err, no. This is explicitly about scaling.
I use 200% scaling on the desktop, and this exact checkbox makes Steam use 2x as well.
I use 200% scaling on the desktop, and this exact checkbox makes Steam use 2x as well.
Working in strides because they don't want to get shut out of the Windows market. Having a credible alternative stay's Microsoft's hand about going Apple and requiring apps only come from the store except for Enterprise editions.
Not trying to play devils advocate here, but who genuinely believes a Linux Steam client is a "credible alternative" to Steam on Windows?
It's an alternative, I agree, but I can't imagine a world in which it makes a dent on their Windows revenues any time soon. If Microsoft try to really force Store only app distribution on all users, I think Valve's time would likely be better spent in the courts than trying to get hundreds of millions of users to install Linux.
It's an alternative, I agree, but I can't imagine a world in which it makes a dent on their Windows revenues any time soon. If Microsoft try to really force Store only app distribution on all users, I think Valve's time would likely be better spent in the courts than trying to get hundreds of millions of users to install Linux.
It's usually better to have established alternatives before they're needed than to try and establish one after significant hurdles have been put in place. I'd say Steam on Linux is plenty credible without currently being a threat to Microsoft.
"If Microsoft try to really force Store only app distribution on all users, I think Valve's time would likely be better spent in the courts than trying to get hundreds of millions of users to install Linux."
Valve has fuck-you money, they'd do both. Having Linux Steam development on a trickle gives them a massive time advantage, in that they already have a few years of experience with the project on day zero of the "we need a Windows-par Steam Linux client" focus.
Valve has fuck-you money, they'd do both. Having Linux Steam development on a trickle gives them a massive time advantage, in that they already have a few years of experience with the project on day zero of the "we need a Windows-par Steam Linux client" focus.
It's interesting you say that, because my response to Epic when they sued Apple was that their time would be better spent contributing to an open platform for phones.
[deleted]
It's beyond scope of a hacker news comment for me, but Epic case against Apple/Google store distribution terms is sufficiently different IMO.
How exactly would Epic ship this open platform when Google and Apple expressly control what apps run and do not? From where I stand, without intervention their only option is inferior browser based streaming solutions like this:
https://www.theverge.com/2020/11/5/21551152/fortnite-nvidia-...
Courts are worth a gamble, worst case scenario Epic is back where it began (minus the legal fees of course), paying Apple/Google 30 percent and still selling plenty of software on the app stores. The Epic case also works to serve Epic's wider public agenda against app stores as litigation theatre too if nothing else.
How exactly would Epic ship this open platform when Google and Apple expressly control what apps run and do not? From where I stand, without intervention their only option is inferior browser based streaming solutions like this:
https://www.theverge.com/2020/11/5/21551152/fortnite-nvidia-...
Courts are worth a gamble, worst case scenario Epic is back where it began (minus the legal fees of course), paying Apple/Google 30 percent and still selling plenty of software on the app stores. The Epic case also works to serve Epic's wider public agenda against app stores as litigation theatre too if nothing else.
By open platform I meant they they should release their own phone. I believe they could do it for not much more than the price of the lawsuit.
The iPhone is not even a general purpose computer, it's a brick of consumer electronics that just happens to have an app store on it. It's Apples house and they get to make the rules. If Epic doesn't like it they can build their own house, or they can contribute to a house that is free for everybody.
I see Valve contributing to an open house that is free for everybody just in case Microsoft stops inviting 3rd parties into their house.
The iPhone is not even a general purpose computer, it's a brick of consumer electronics that just happens to have an app store on it. It's Apples house and they get to make the rules. If Epic doesn't like it they can build their own house, or they can contribute to a house that is free for everybody.
I see Valve contributing to an open house that is free for everybody just in case Microsoft stops inviting 3rd parties into their house.
Good luck _selling_ that phone to the hundreds of millions of users you lost immediately overnight, to users already perfectly happy with the phone they have. Your customers aren't going to pickup the tab just because you didn't like the distribution terms you had already willingly agreed to on iOS/Google app stores, and its a big tab. A new phone isn't cheap for most. I am also completely ignoring the fact building a competitive phone is likely really hard and Epic have no track record there.
I'd love to be proved wrong of course - who doesn't like a cool new tech platform succeeding? Being realistic though, there isn't exactly a long list of new mobile hardware/OS platforms launching at the scale and success Epic would need to replace lost iOS/Android revenue. In fact, no one has ever managed to do that really! That Epic have already partnered with Nvidia to use browser streaming tech to get Fortnite back onto iOS suggest similar thinking to me. Epic's own lawyers are making similar arguments right now too.
Imagine if every railway company had to build it own tracks, or every airline needed its own airports. Conceptually, app stores on mobile platforms are increasingly similar. It's not practical to keep building more airports and more track networks, especially when in this case the airport or network is a handset the customer has to buy. The railway example is one Courts had to deal with in early 20th century in a lot of countries, same too for shipping ports.
I'd love to be proved wrong of course - who doesn't like a cool new tech platform succeeding? Being realistic though, there isn't exactly a long list of new mobile hardware/OS platforms launching at the scale and success Epic would need to replace lost iOS/Android revenue. In fact, no one has ever managed to do that really! That Epic have already partnered with Nvidia to use browser streaming tech to get Fortnite back onto iOS suggest similar thinking to me. Epic's own lawyers are making similar arguments right now too.
Imagine if every railway company had to build it own tracks, or every airline needed its own airports. Conceptually, app stores on mobile platforms are increasingly similar. It's not practical to keep building more airports and more track networks, especially when in this case the airport or network is a handset the customer has to buy. The railway example is one Courts had to deal with in early 20th century in a lot of countries, same too for shipping ports.
I don't have much sympathy for anybody who helped Google and Apple into the monopoly position by making their products available on those platforms. If we all banded together and made sure that all the best apps were only available on a truly open phone platform then everybody would buy a phone on that platform.
Epic could pump a few million into making sure their games ran well on Linux platforms, then partner with Asus, Razer, and others to make Gaming Phones a real thing with support for Linux on those phones. (or a Google free Android if that will lower the bar).
I think the railways and airports are not a good analogy because those are physical things that need a lot of land. (and investment) We are just talking about software, and what we can and cannot run on our phones.
Epic could pump a few million into making sure their games ran well on Linux platforms, then partner with Asus, Razer, and others to make Gaming Phones a real thing with support for Linux on those phones. (or a Google free Android if that will lower the bar).
I think the railways and airports are not a good analogy because those are physical things that need a lot of land. (and investment) We are just talking about software, and what we can and cannot run on our phones.
You are shipping "bits" to phones, just as boats and trains shipped cargo to stations and ports. Its fundamentally analogous as a legal argument; whether it's corporeal items being moved (physical goods) or not doesn't really matter. The principle is the same.
I cannot ever advise a company like Epic to burn its business model overnight on a such a huge risk as you suggest, I'm sure many would agree. You of course are free to continue to disagree and advocate for a new Epic phone platform to sell.
Epic today have 116 million users by their count playing Fortnite on an iOS device. That's a lot of users to convince to pay likely at least several hundred dollars to move to a platform that doesn't exist yet. I didn't even bother to look up the Android count, the iOS user base is enough to illustrate why this is likely a pretty bad business decision.
I cannot ever advise a company like Epic to burn its business model overnight on a such a huge risk as you suggest, I'm sure many would agree. You of course are free to continue to disagree and advocate for a new Epic phone platform to sell.
Epic today have 116 million users by their count playing Fortnite on an iOS device. That's a lot of users to convince to pay likely at least several hundred dollars to move to a platform that doesn't exist yet. I didn't even bother to look up the Android count, the iOS user base is enough to illustrate why this is likely a pretty bad business decision.
> How exactly would Epic ship this open platform when Google and Apple expressly control what apps run and do not?
By sidestepping Google's Play Store and encouraging sideloading (whether by directly downloading a game's .apk or by pushing an alternative app store like what Amazon and F-Droid do), for one.
That is: any Android ROM that allows sideloading (which, last I checked, is most of them) is already that "open platform" (in the Windows sense of not restricting what software runs on it, rather than the free software sense).
By sidestepping Google's Play Store and encouraging sideloading (whether by directly downloading a game's .apk or by pushing an alternative app store like what Amazon and F-Droid do), for one.
That is: any Android ROM that allows sideloading (which, last I checked, is most of them) is already that "open platform" (in the Windows sense of not restricting what software runs on it, rather than the free software sense).
Its an alternative in a same way Tizen is Samsungs alternative to Android, or Munich Linux deployment. Its there to get favorable treatment, nothing more.
I suspect Valve's interest is more in pushing PC gaming as a hardware platform. You saw some of that with the Steam Link and Steam Controller. I suspect they want to resurrect the Steam Machine and sell it with Linux OEM. If they start selling a portable (like the Switch or even the 3DS), I'd buy it on day one.
What all of these have in common is that they would be easier (and probably more profitable) if you can make the operating system cheaper.
What all of these have in common is that they would be easier (and probably more profitable) if you can make the operating system cheaper.
Is it perhaps because Steam Client is being "worked on" by Valve employees (do whatever you want, no bosses, but if you work on something we wont like you will be fired immediately, ask Jeri Ellsworth) while DirecX compatibility is all volunteers with maybe some funding? I googled Hans-Kristian Arntzen (VKD3D-Proton maintainer?) and he doesnt appear to be employed by Valve.
Correct. SteamOS is a passion project by Gabe because of a grudge with Microsoft, and it's basically all contractors. Nobody at Valve internal gives a shit, in fact they're more worried about Epic Games than MS.
It could also be because it makes economic sense for Valve to make their software portable. Being tied to Direct3D, which only runs on Windows, is not in any way futureproof. I'm not following Valve closely, but they used to be working on the Steam Machine, and they have VR aspirations. I don't think they'd want to have to buy Windows licenses for their custom gaming hardware. I'm not sure how active those projects are right now, but regardless, if your game engines are tied to Windows, it locks down your future options, Microsoft has you by the balls. To maximize profits and future opportunities, you'd want to be able to write once and port easily to Mac, Linux, cellphones, consoles, VR headsets, etc.
More likely, it was an attempt for Steam to compete with consoles - Steam can run on HTPCs with Big Picture, but consoles are (or at least were) all about the OOTB experience. It makes a lot of sense to simply ship a pre-configured OS when pushing HTPCs.
You could say that making it Linux-based shows that SteamOS is all about Windows, but if anything that logic suggests it's all about the Xbox. If it were competing with Windows it'd be a KB+M-based distro.
If you say "but they didn't need a separate Linux distro, they were already focusing on Ubuntu", that just proves that SteamOS wasn't about Windows.
You could say that making it Linux-based shows that SteamOS is all about Windows, but if anything that logic suggests it's all about the Xbox. If it were competing with Windows it'd be a KB+M-based distro.
If you say "but they didn't need a separate Linux distro, they were already focusing on Ubuntu", that just proves that SteamOS wasn't about Windows.
contractors who are already experienced/motivated to work on linux probably make more sense for that kind of thing anyway
At the very least Plagman seems to still be working on Linux stuff inside Valve. There have been lots of other too (may or may not have changed) so it's definitely not just "a passion project by Gabe".
What happened with Jeri Ellsworth? I love her work. I vaguely remember her spinning out her Valve project into a new company backed by Valve. I believe there was a Kickstarter.
That article didn't really say what happened, it just listed a bunch of complaints about structurelessness (not just at Valve), while itself lacking structure.
Honestly I can tolerate those things if it means I can game on Linux and have no need to keep a copy of Windows installed.
It's been 5 years or so since I moved all my computers over to Linux (was not a cortana fan) and proton definitely made the transition easier.
It's been 5 years or so since I moved all my computers over to Linux (was not a cortana fan) and proton definitely made the transition easier.
Yeah, true. As much as I complain, I still use Steam.
It never occurred to me to boot into windows for gaming though -- once I moved I quickly wiped windows and never looked back (like ten years ago now).
It never occurred to me to boot into windows for gaming though -- once I moved I quickly wiped windows and never looked back (like ten years ago now).
That's because they're working on Linux support, they don't care about Linux desktop. Steam os is based on Linux, but it would be naive to think they put much work in supporting Linux desktop, since the market share is neglibe.
I think the general idea here is that if you're competent enough with Linux to build something as useful as proton, you should be able to do something as simple as make a proper Linux client.
Having said that, I haven't experienced any of the issues mentioned.
Having said that, I haven't experienced any of the issues mentioned.
I'm not kidding when I say that deep technical work like building proton is a lot easier in some sense then building a good multiplatform UI.
What's interesting is that games are one of the main reasons the market share is negligible. It used to be games and Office, but home users can increasingly get by with the web version or Google Docs or LibreOffice. But people still keep Windows on their PCs for games.
If the games start to run on Linux, what's still keeping people on Windows?
If the games start to run on Linux, what's still keeping people on Windows?
Google Docs is no replacement for actual serious work in Office. That's like asking someone who uses NetBeans to switch over to repl.it
Sure, but a lot of companies have switched. My previous job was a banking company with thousands of employees and they were using Google's suite for everything. So while Office is still ahead for serious work, there are more and more large companies out there who have migrated away.
From what I see when I step in to help various organisations improve I'd argue the opposite. Google docs improves coordination, which is the largest real cost of using ms office. To the point where most orgs have structured their whole operation around _how_ they are used to using ms office, with it's limitations. Stepping away from ms office allows concurrent distributed work, which radically improves efficiency.
google docs is a low friction entry into modern work coordination. It's not what I recommend for heavy work. But for heavy work ms office fails as well, just a little bit later, and with more costly result.
google docs is a low friction entry into modern work coordination. It's not what I recommend for heavy work. But for heavy work ms office fails as well, just a little bit later, and with more costly result.
This "actual serious work" you mention is not what most people use Office for anyway.
Most people write simple letters, and do very basic spreadsheets.
This is probably one of those "80% of the people use 20% of the features" scenario.
Most people write simple letters, and do very basic spreadsheets.
This is probably one of those "80% of the people use 20% of the features" scenario.
'This "actual serious work" you mention is not what most people use Office for anyway.
Most people write simple letters, and do very basic spreadsheets.'
Most "actual serious work" involves receiving and modifying other peoples' drafts. As such, if anyone uses an advanced feature, everyone uses the advanced feature.
Most people write simple letters, and do very basic spreadsheets.'
Most "actual serious work" involves receiving and modifying other peoples' drafts. As such, if anyone uses an advanced feature, everyone uses the advanced feature.
> If the games start to run on Linux, what's still keeping people on Windows?
Let me tell you a story:
In the late 1940s the US airforce had a serious problem: many pilots were dying in incidents caused by apparent pilot error. At one point this number reached 17 pilots a day. After ruling out training as a cause, they turned their attention to ergonomics. In the 1920s, they had conducted a study to determine the physical dimensions of the average pilot and standardized all cockpit layout based on said average. Naturally, they suspected that the average pilot had changed over the nearly-two-decades since and conducted another study. With over 140 measurements of over 4,000 pilots they expected to be able to create a new standard for cockpit dimensions and layout that would better fit the contemporary average pilot.
And they probably would have done just that, if not for Lt. Gilbert S. Daniels. Daniels was a junior researcher assigned to taking the measurements. Due to his previous work on human body measurements, Daniels believed that designing for the average pilot was useless at best. Daniels created a picture of the average pilot the military wanted, which he defined as being in the middle 30% of values in each measurement, and then demonstrated that exactly 0 pilots in the study matched all 10 of the dimensions determined to be most relevant. Further, even when you chose only 3 such dimensions, fewer than 4% of pilots matched.
The conclusion was that there was no such thing as the average pilot and if you designed around this fictional entity your cockpit wouldn't fit anybody. If you wanted to have pilots that fit the cockpit, you had to design cockpits that would adjust to fit individual pilots.
The lesson? Linux Desktop evangelists seem to expect that people should love Linux Desktop because they worked so hard to make it usable for what they imagine is the average user, apparently completely ignorant that there is no such person. Desktops are personal devices that need to be able to accommodate the user's individual workflows. Does Windows excel at this? Well, not really and it has been getting worse, but Windows accommodates software in a way that Linux Desktop doesn't: it isn't hostile to commercial software, it works hard at maintaining compatibility with old software, and it allows for direct distribution from developer to user without middlemen gumming up the works. That enables third parties to help users fit their computer to their workflow. Linux Desktop is bad at all these things and though it is theoretically more adjustable, the reality is that trying to fit it to your usecases is an exercise in fighting this average user mentality and often involves dealing with a ludicrously complex intertwined system of mis-matched components at a very intimate level.
That's what is keeping people on Windows.
Let me tell you a story:
In the late 1940s the US airforce had a serious problem: many pilots were dying in incidents caused by apparent pilot error. At one point this number reached 17 pilots a day. After ruling out training as a cause, they turned their attention to ergonomics. In the 1920s, they had conducted a study to determine the physical dimensions of the average pilot and standardized all cockpit layout based on said average. Naturally, they suspected that the average pilot had changed over the nearly-two-decades since and conducted another study. With over 140 measurements of over 4,000 pilots they expected to be able to create a new standard for cockpit dimensions and layout that would better fit the contemporary average pilot.
And they probably would have done just that, if not for Lt. Gilbert S. Daniels. Daniels was a junior researcher assigned to taking the measurements. Due to his previous work on human body measurements, Daniels believed that designing for the average pilot was useless at best. Daniels created a picture of the average pilot the military wanted, which he defined as being in the middle 30% of values in each measurement, and then demonstrated that exactly 0 pilots in the study matched all 10 of the dimensions determined to be most relevant. Further, even when you chose only 3 such dimensions, fewer than 4% of pilots matched.
The conclusion was that there was no such thing as the average pilot and if you designed around this fictional entity your cockpit wouldn't fit anybody. If you wanted to have pilots that fit the cockpit, you had to design cockpits that would adjust to fit individual pilots.
The lesson? Linux Desktop evangelists seem to expect that people should love Linux Desktop because they worked so hard to make it usable for what they imagine is the average user, apparently completely ignorant that there is no such person. Desktops are personal devices that need to be able to accommodate the user's individual workflows. Does Windows excel at this? Well, not really and it has been getting worse, but Windows accommodates software in a way that Linux Desktop doesn't: it isn't hostile to commercial software, it works hard at maintaining compatibility with old software, and it allows for direct distribution from developer to user without middlemen gumming up the works. That enables third parties to help users fit their computer to their workflow. Linux Desktop is bad at all these things and though it is theoretically more adjustable, the reality is that trying to fit it to your usecases is an exercise in fighting this average user mentality and often involves dealing with a ludicrously complex intertwined system of mis-matched components at a very intimate level.
That's what is keeping people on Windows.
There is commercial software on Linux - steam, opera, chrome, telegram, skype. I hope Flatpak and Wayland would provide secure way to run it, runtimes would solve compatibility issues — requisites for direct distribution. Distribution patches is choice of the user, for example Arch is upstream.
I do not think people switch to Linux because of love. They switch because they hate their OS. The question was about lowering yet another barrier.
> Linux Desktop is bad at all these things and though it is theoretically more adjustable, the reality is that trying to fit it to your usecases is an exercise in fighting this average user mentality and often involves dealing with a ludicrously complex intertwined system of mis-matched components at a very intimate level.
The reality is on Linux usually it is already done — someone wrote code, packaged it, wrote articles, posted on forums, made desktop or distribution around it. Something that's not possible on Windows.
Windows is monoculture, deployment platform but stay away from the system.
I do not think people switch to Linux because of love. They switch because they hate their OS. The question was about lowering yet another barrier.
> Linux Desktop is bad at all these things and though it is theoretically more adjustable, the reality is that trying to fit it to your usecases is an exercise in fighting this average user mentality and often involves dealing with a ludicrously complex intertwined system of mis-matched components at a very intimate level.
The reality is on Linux usually it is already done — someone wrote code, packaged it, wrote articles, posted on forums, made desktop or distribution around it. Something that's not possible on Windows.
Windows is monoculture, deployment platform but stay away from the system.
Interesting story. I personally find Linux (gnome) desktop to be easier to personalize than windows though. Easy to add 3rd party ppas, easy to add or replace functionality. Compatibility with old software isn’t great though
Personalization and GNOME are mutually exclusive. But it's a nice laptop DE.
For a workstation, you want KDE. It's the most full-featured and Windows-like and customizable DE, by far. Also, try Manjaro, so that you don't have to fiddle with PPAs or OS upgrade re-installations and have ALL the newest software (via the AUR) all the time, like you do on Windows. : p
For a workstation, you want KDE. It's the most full-featured and Windows-like and customizable DE, by far. Also, try Manjaro, so that you don't have to fiddle with PPAs or OS upgrade re-installations and have ALL the newest software (via the AUR) all the time, like you do on Windows. : p
I'm guessing you don't actually run a Linux Desktop. KDE is significantly more customizable than windows.
> I'm guessing you don't actually run a Linux Desktop.
Wrong. Until about 6 months ago the majority of PCs I owned ran Linux Desktop. Eventually I just got sick of dealing with its nightmarish tangle of half-thought-out systems and currently it only runs on one.
KDE is very configurable, but that's only one component of the entire system (and it still has some odd limitations in my opinon).
I've been running Linux Desktop (and Linux as a server for that matter) to varying degrees for 20 years now, have contributed to open source projects, and was once president of a LUG. I still think Linux Desktop has a ton of problems and would rather use Windows. I don't know if you're able to square that with your worldview or not, but that isn't my problem.
Wrong. Until about 6 months ago the majority of PCs I owned ran Linux Desktop. Eventually I just got sick of dealing with its nightmarish tangle of half-thought-out systems and currently it only runs on one.
KDE is very configurable, but that's only one component of the entire system (and it still has some odd limitations in my opinon).
I've been running Linux Desktop (and Linux as a server for that matter) to varying degrees for 20 years now, have contributed to open source projects, and was once president of a LUG. I still think Linux Desktop has a ton of problems and would rather use Windows. I don't know if you're able to square that with your worldview or not, but that isn't my problem.
Woah, apologies if my comment was too short and came across as snarky. Sounds like are a lot more familiar with Linux Desktop than me. I'm fairly new (a few years) and for me everything just works and is more configurable. I am constantly battling with Windows in a way I do not on my Linux system. In my mind, KDE is a better desktop, but I am still forced to use windows because there are a few tools that don't have good Linux alternatives.
I hate how right you are.
Cortana.
>Cortana
Agreed, Cortana is a big reason to avoid Windows.
Agreed, Cortana is a big reason to avoid Windows.
If only we could disable that creepfest
Supporting the Linux desktop means they can leverage more of it for whatever solution they ship.
They can either use an existing display server, or write their own. The latter would be absurdly more expensive.
They can either use an existing display server, or write their own. The latter would be absurdly more expensive.
Don't worry I'm still on Windows 7 and it is also a crashy mess for me.
Steam, Lutris, PlayOnLinux have done a great job sanding the edgy surfaces of great projects like Wine, DXVK, etc.
ProtonDB and WineHQ are good resources for users as well.
ProtonDB and WineHQ are good resources for users as well.
The client works fine on XWayland, but the games do not, I need to switch to X11 for that. I really only use the client to launch the games though, so I haven't noticed any of the other issues.
As far as the games go, I've been very impressed with how well Proton works so far! I was thinking about running Windows in a VM and doing GPU passthrough when I get a desktop next year, but with how well Proton has been working on my laptop (with only integrated gpu), I may not need to -- Proton may work perfectly well. In X11 (sadly, since I use Sway for my non-gaming use).
As far as the games go, I've been very impressed with how well Proton works so far! I was thinking about running Windows in a VM and doing GPU passthrough when I get a desktop next year, but with how well Proton has been working on my laptop (with only integrated gpu), I may not need to -- Proton may work perfectly well. In X11 (sadly, since I use Sway for my non-gaming use).
Isn't Xwayland supposed to have proper support for GPU acceleration now? Does it just not work well?
There's also this port [0] of wine to Wayland but it only supports simple fully GPU-drawn windows AFAIK (not desktop apps). So, sufficient for playing many games. I haven't tried it yet.
[0] https://github.com/varmd/wine-wayland
There's also this port [0] of wine to Wayland but it only supports simple fully GPU-drawn windows AFAIK (not desktop apps). So, sufficient for playing many games. I haven't tried it yet.
[0] https://github.com/varmd/wine-wayland
I'm not sure what the issue is tbh. The games launch, but in my testing, have all kinds of glitches or issues that go away when running on X11. For example, one game doesn't receive any input, another one has graphical artifacts but otherwise runs fine, another runs at a suuper low frame rate. All of these issues go away when running on X. For all I know its a driver issue or something else in my setup.
But things are improving, so maybe in a few months (by the time I get a desktop with some luck) it will all be resolved. I may give wine-wayland a try too if it's not. Or its my setup and it may just work on new hardware.
Either way, I'm quite impressed by Proton, but haven't been able to run it on Wayland properly yet.
But things are improving, so maybe in a few months (by the time I get a desktop with some luck) it will all be resolved. I may give wine-wayland a try too if it's not. Or its my setup and it may just work on new hardware.
Either way, I'm quite impressed by Proton, but haven't been able to run it on Wayland properly yet.
> The client works fine on XWayland
XWayland does not support scaling, so I don't see how it can "work fine".
XWayland does not support scaling, so I don't see how it can "work fine".
Well, I haven’t noticed any issues so it’s “worked fine” for me. Doesn’t mean the issues aren’t there, just that they haven’t affected me. So for anyone who hasn't needed scaling, I think it works pretty well.
It also still requires 32-bit drivers, which were initially missing from the last nvidia update, forcing a rollback.
I'm incredibly grateful for the work they've done on Proton, but it's definitely odd they don't seem to have anyone prioritizing updating the Steam platform itself.
I'm incredibly grateful for the work they've done on Proton, but it's definitely odd they don't seem to have anyone prioritizing updating the Steam platform itself.
A lot of old games are 32 bit only and won't be ported to bit.
The main window is also very laggy and unresponsive.
One day, I found myself on Windows again and opened Steam there, and I was surprised and a little delighted that Steam was just as laggy and unresponsive there too. c:
One day, I found myself on Windows again and opened Steam there, and I was surprised and a little delighted that Steam was just as laggy and unresponsive there too. c:
fwiw, Steam's HiDPI support was rubbish on Windows until relatively recently, so it's not weird that it's bad on Linux as well.
Valve is doing god’s work when it comes to Linux gaming. I have played over 40 hours of GTA V without many troubles. The game looks great and performs great. So glad I could get rid of my windows install.
If I remember correctly, Valve started doing this some time ago as an "insurance policy", when Microsoft spoke about locking down Windows (before they introduced Windows Store).
It is amazing to see how far Linux gaming has come since then. 10 years ago almost none of the big games worked, 5 years ago lots of games worked after fiddling with wine config, and now most of the games I have tried work out of the box after enabling Proton.
Imagine what will come in the next 5 to 10 years.
It is amazing to see how far Linux gaming has come since then. 10 years ago almost none of the big games worked, 5 years ago lots of games worked after fiddling with wine config, and now most of the games I have tried work out of the box after enabling Proton.
Imagine what will come in the next 5 to 10 years.
Yeah, Steam continuously investing on Linux is what keeps MS in check.
Microsoft knows they can't lock down the OS while gaming on Linux [at least] works.
It's truly an insurance policy, and they have to pay it each month -- if they let Linux gaming lag behind long enough, they lose their ground on MS.
Microsoft knows they can't lock down the OS while gaming on Linux [at least] works.
It's truly an insurance policy, and they have to pay it each month -- if they let Linux gaming lag behind long enough, they lose their ground on MS.
Microsoft and other game makers will try pushing more exclusives to reduce Valve's "market share".
Microsoft recently bought ZeniMax, which makes lots of popular titles that I played on Steam. Unreal is working on their own game store. PS and Xbox has had exclusives for years.
If it keeps going this direction, Valve will have to pull a rabbit out of their hat. Either by making some great games again or surprising us with something completely new.
Competition is great for consumers, but I am somewhat rooting for the guys that improve free, open source software in the process.
Microsoft recently bought ZeniMax, which makes lots of popular titles that I played on Steam. Unreal is working on their own game store. PS and Xbox has had exclusives for years.
If it keeps going this direction, Valve will have to pull a rabbit out of their hat. Either by making some great games again or surprising us with something completely new.
Competition is great for consumers, but I am somewhat rooting for the guys that improve free, open source software in the process.
> Unreal is working on their own game store.
This is so sad. Just fragmenting the market more merely increases the influence of MS.
> PS and Xbox has had exclusives for years.
These don't really compete with PCs. People stick to one, another, or both. Seldom do gamers suddenly switch from PC to console and completely drop their PC.
This is so sad. Just fragmenting the market more merely increases the influence of MS.
> PS and Xbox has had exclusives for years.
These don't really compete with PCs. People stick to one, another, or both. Seldom do gamers suddenly switch from PC to console and completely drop their PC.
The Epic store is the first significant competitor to Steam. They take a lower cut of game sales than Steam does. I wouldn’t lose sleep over market fragmentation.
Consumers gain nothing from "competition" if they are forced to use both providers due to exclusives. If Epic would actually compete on features then that would be a good thing, but right now they are just dumping money into developers to gain marketshare while not actually improving anything for end users.
HL3
"Some time ago" was eight years ago (/r/linux_gaming reminded me of this). Amazing they kept going through all this time and do not seem to slow down.
I remember when the xcom reboot launched and it was a notable fact that there was a clone of the original xcom with 3d graphics. because that was the Linux gaming scene, openttd, wesnothn and emulation.
It's still amazing to me now that the only games I don't play on Linux are MMOs and competitive multiplayer because I'm worried about being banned by an overzealous anticheat. And by all accounts , the games in those categories I like do work on proton
It's still amazing to me now that the only games I don't play on Linux are MMOs and competitive multiplayer because I'm worried about being banned by an overzealous anticheat. And by all accounts , the games in those categories I like do work on proton
All that is needed now is working with the most-used anti-cheat companies. It sucks when a game works perfectly but you get booted (and possibly banned) for running Linux.
Does anyone have a good write-up on the history behind Linux gaming? Would love to learn more
I don't have a writeup but the main highlights have been
1. Loki Entertainment [0] (1988-2001), a third-party porting company that licensed games and released them for Linux
2. Linux Game Publishing [1] (2001-2009), basically continued what Loki was doing
3. id Software used to release their games for Linux and open source the engines [2]
4. Others (mostly Indies) also had Linux ports, but it was still rare: Frictional (Penumbra series, Amnesia), 2D Boy (World of Goo), ... and Wolfire Games who created:
5. Humble Indie Bundle [3] (2010-) incentivized many popular Indie games to be ported to Linux - initially all Bundles where 100% cross-platform between Windows, Linux and OS X.
6. Steam for Linux [4] (beta 2012, 2013-) - with the lure of Steam Machines many more developers jumped onto Linux ports, including some larger Publishers as well as porting companies: Aspyr, Feral Interactive, Virtual Programming (eON)
7. GOG.com Linux support [5] (2014-)
8. DXVK, Proton (2018-) making it easier to play Windows games
There was also Kickstarter where for a while most big ones had Linux support promised in some form. Also Unity adding Linux exports has made it possible for tons of games to be ported (although not without issues). I probably forgot some things, but at least that should be a lot you can read up on.
[0] https://en.wikipedia.org/wiki/Loki_Entertainment
[1] https://en.wikipedia.org/wiki/Linux_Game_Publishing
[2] https://en.wikipedia.org/wiki/Id_Software#Linux_gaming
[3] https://en.wikipedia.org/wiki/Humble_Bundle
[4] https://store.steampowered.com/news/9943/
[5] https://www.gog.com/news/gogcom_now_supports_linux
1. Loki Entertainment [0] (1988-2001), a third-party porting company that licensed games and released them for Linux
2. Linux Game Publishing [1] (2001-2009), basically continued what Loki was doing
3. id Software used to release their games for Linux and open source the engines [2]
4. Others (mostly Indies) also had Linux ports, but it was still rare: Frictional (Penumbra series, Amnesia), 2D Boy (World of Goo), ... and Wolfire Games who created:
5. Humble Indie Bundle [3] (2010-) incentivized many popular Indie games to be ported to Linux - initially all Bundles where 100% cross-platform between Windows, Linux and OS X.
6. Steam for Linux [4] (beta 2012, 2013-) - with the lure of Steam Machines many more developers jumped onto Linux ports, including some larger Publishers as well as porting companies: Aspyr, Feral Interactive, Virtual Programming (eON)
7. GOG.com Linux support [5] (2014-)
8. DXVK, Proton (2018-) making it easier to play Windows games
There was also Kickstarter where for a while most big ones had Linux support promised in some form. Also Unity adding Linux exports has made it possible for tons of games to be ported (although not without issues). I probably forgot some things, but at least that should be a lot you can read up on.
[0] https://en.wikipedia.org/wiki/Loki_Entertainment
[1] https://en.wikipedia.org/wiki/Linux_Game_Publishing
[2] https://en.wikipedia.org/wiki/Id_Software#Linux_gaming
[3] https://en.wikipedia.org/wiki/Humble_Bundle
[4] https://store.steampowered.com/news/9943/
[5] https://www.gog.com/news/gogcom_now_supports_linux
Call me optimistic, but I imagine a larger amount of "most" work out of the box by then.
A lot of games now don't work because of anti-cheat technologies. But Valve is working on this with Codeweavers with their refactoring of NTDLL.
The most egregious anti-cheat stuff is actually implemented in a windows kernel driver - I'm not optimistic about this being resolved without first party support for Linux.
Collabora guys are working on just that, FYI.
i'm not touching games which do that
Welcome to any competitive multiplayer game in 2020.
My favorite example is PUBG and their insecure netcode (for the first 2 years it was entirely unencrypted). At one point the cheating was so predominant that they banned anyone running VirtualBox and the game at the same time. I was swept up in that because I had a background dev VM running that I forgot about.
My favorite example is PUBG and their insecure netcode (for the first 2 years it was entirely unencrypted). At one point the cheating was so predominant that they banned anyone running VirtualBox and the game at the same time. I was swept up in that because I had a background dev VM running that I forgot about.
As a side note, it always tickles me pink when I'm noticing a game is stuttering a little and then I realize I have 4-5 VMs running in the background. Have to love how far technology is come. 8 years ago I was struggling to run games with a browser open and now i have 5 browsers running at once in the background each in their own VM while playing AAA games at 60fps.
Kernel anti cheat rootkits meanwhile server doesnt even perform the most basic sanity checks, like
is client entity running at the speed of light?
is client entity teleporting all over the map?
is client entity allowed to fly?
or asking really "hard" questions, like
should server really send detailed position and model data (animation frame, items equipped etc) of players not in a Potentially visible set to client entity?
is client entity running at the speed of light?
is client entity teleporting all over the map?
is client entity allowed to fly?
or asking really "hard" questions, like
should server really send detailed position and model data (animation frame, items equipped etc) of players not in a Potentially visible set to client entity?
That last part is what really annoys me. Do visibility checks on the server not the client.
But then you need to pay for hardware to run those checks! (Unless of course you let players run their own servers, but then you loose control and might have your old game that refuses to die compete with your newer ones.)
> without first party support for Linux.
Or for wine
Or for wine
Anticheat is just spyware that gamers have grudgingly let run on their systems. I’d rather not play those games when I have the choice. I am 100% not aware of which games use it except for 7 days to die that mentions it in the launcher
I think that the only gaming company that actively improve Linux gaming is only Valve. Compare this to Stadia, where I never see any news on them contributing to the Linux gaming stack
Well.. and Aspyr for porting. And CodeWeavers for employing Wine devs.
And Collabora: https://www.gamingonlinux.com/2020/10/collabora-expect-their...
And Collabora: https://www.gamingonlinux.com/2020/10/collabora-expect-their...
Aspyr has not been doing any porting for years. Feral is scaling down their porting as well. Mainly because of Proton: https://boilingsteam.com/proton-the-native-port-killer/
Yeah, really sad to see this. When Aspyr released Farenheit and KotOR 2 I was really excited for getting more older games ported but it seems they dropped that.
It's just not economical when Proton does the porting "for free" compared to 6-months ports by Aspyr/Feral for very little change in performance.
Right, I forgot about those Linux porting companies such as Aspyr and Feral Interactive. And Collabora isn't specifically a gaming company, but they and CodeWeavers also helps
Both Collabora and CodeWeavers collaborate with Valve (and with funding from Valve?) on the gaming front though so it's not wrong to attribute that to Valve (yes CodeWeavers also improves Wine independently, but that's more than just games).
Codeweavers is mainly working to support Proton these days, check out this interview from a few days ago: https://boilingsteam.com/podcast-12-with-james-ramey-from-co...
Another big catalyst IMO was Unity's seamless build for many platforms, including Linux.
It came in parallel with the Kickstarter boom, where a lot Kickstarter campaigns would offer Linux support as a way to entice a new audience. The time around 2010-12 was pivotal for Linux gaming and indie gaming alike.
It came in parallel with the Kickstarter boom, where a lot Kickstarter campaigns would offer Linux support as a way to entice a new audience. The time around 2010-12 was pivotal for Linux gaming and indie gaming alike.
Well Stadia themselves have barely started making first party games, whereas Valve not only makes games, but also makes their own game engine, and have for decades. These improvements you see on Linux have been over 8 years in the works, Stadia has only been around for a year.
I would also assume that by getting devs to port their games to Linux to run on Stadia, the contribution may be more indirect. You'll get more game studios contributing to the stack, even if Stadia themselves aren't yet.
I would also assume that by getting devs to port their games to Linux to run on Stadia, the contribution may be more indirect. You'll get more game studios contributing to the stack, even if Stadia themselves aren't yet.
Stadia does have a number of open source repos oh GitHub. https://github.com/googlestadia
*I work at Google but not on anything related to Stadia.
*I work at Google but not on anything related to Stadia.
Feral Interactive has also contributed to the OSS AMD drivers.
I bought Civ 6 for Linux purely because it was available on Linux. Bought from Steam. It does seem like they're pushing things in the right direction for Linux gaming.
One thing that's important for Linux gaming is that games played under Proton on Steam are counted as Linux sales, so publishers and developers get accurate statistics on how many Linux gamers there are.
If the market is big enough, cross platform development is viable from the start.
If the market is big enough, cross platform development is viable from the start.
On the other hand, if the Windows version works fine with Vulcan, why go through the trouble of making a Linux version?
Precisely, and developing for Windows is much easier than Linux anyway because it doesn't suffer from the same "lets break userspace every 2 years" problem.
I know that games are hectic and everything but I am still genuinely confused that porting a game is this complicated.
The main meat and potatoes of the game is either nearly platform agnostic (Vk, OpenGL, or emulation) or usually similar in principle (audio).
Maybe I've been spoilt by only working on open source projects where people try to write good code because it's public.
The main meat and potatoes of the game is either nearly platform agnostic (Vk, OpenGL, or emulation) or usually similar in principle (audio).
Maybe I've been spoilt by only working on open source projects where people try to write good code because it's public.
We didn't port our game Void Bastards to Linux because the sales are _so_ low we won't see a return on investment. Yes its easy these days, but there is still a few days messing around with builds and a few days testing. There is a good chance we won't see a week of salary as a return.
If you see how hard of a time publishers have to get their games running on the wide range of Windows PCs, especially at release, it's easy how they don't want to add a second operating system to the requirements as well.
Yeah, there's never any issues keeping games working on Windows...
There are sometimes problems, sure, but compared to Linux, where an application compiled 2 years ago for the same distro often won't work on the current version, it's pretty damned good at compatibility.
Age of empires 2 works out of the box on windows 10 ... The game was compiled with Visual Studio 6.0 ... Even that still runs on Win10. So yeah, it's pretty damn good.
> where an application compiled 2 years ago for the same distro often won't work on the current version
Ship non-system libraries with your application instead of assuming they will be in /usr/lib* and that's a solved problem. Valve even does that for you with the Steam runtime.
This isn't any different on Windows - if you don't bundle your dependencies (including MSVCRT / .NET / whatever) then you will run into problems.
Ship non-system libraries with your application instead of assuming they will be in /usr/lib* and that's a solved problem. Valve even does that for you with the Steam runtime.
This isn't any different on Windows - if you don't bundle your dependencies (including MSVCRT / .NET / whatever) then you will run into problems.
As long as the game runs fine and it is supported, that's perfectly fine for me. Most ports use ad hoc emulation layers anyway that never see updates once released, while proton see continuous improvements (but of course it can also regress).
The better ports use the native APIs of course, but are few and far between.
The better ports use the native APIs of course, but are few and far between.
It's probably easier to develop proton support for a Windows than to port the entire game to Linux.
Sure, but my point was that this shows the value in making a game that's easily portable to begin with. This is more for future games rather than converting existing ones.
How so? At the time of sale it's not clear how the user will play the game, especially considering only a few titles are available officially for Proton.
Hm? All titles on Steam when played with Proton are registered as being played on Linux, not just the ones available officially, and if you do this with something you just purchased it will show up in Steam's statistics as a Linux sale.
This lets the publishers and developers know that there's a market of Linux gamers because they can see that X thousand players play their game on Linux. So when they make their next game, hopefully they'll pick technologies that lets them release with proper Linux support and not "hope it runs under Proton"-support.
This lets the publishers and developers know that there's a market of Linux gamers because they can see that X thousand players play their game on Linux. So when they make their next game, hopefully they'll pick technologies that lets them release with proper Linux support and not "hope it runs under Proton"-support.
Do you have a source for this? I don't doubt that's how it works but it doesn't sound likely.
Civ6 was a very poor port on Linux.
Oh god. I have pretty good specs and decided to try to switch my PC over to Linux. At the time all I really wanted to play game-wise was Civ 6. It had a linux port so I'd imagine it would be fine. Dear God was I wrong. I tries it on Ubuntu and it was the only "officially supported" distro. The game was flat out unplayable, FPS drops to the point where I was watching a slide show, UI animations lagged, and attempting to start a multiplayer lobby froze the game at a blank screen, my graphics card showed up as "Unknown Device" despite being dected fine by the Nvidia drivers. I tried for months to figure out was going on. I made sure my graphics drivers were straight, updated firmware, even upgraded to a much more recent kernel and tried different Ubuntu versions. Nothing would work and no one was able to help me out at all. The best lead I found was some very old comments about how the Linux port had atrocious CPU optimization and had basically no multicore support.
Anyway maybe close to a year later, I tried again with Fedora, it ran a bit better, which I imagine to be the work of better updated kernel + system packages, but I had to keep it on the lowest graphics settings to make it barely playable. And this was on a system with a decent mid teir graphics card at the time, more memory than I've ever needed and a Ryzen 9. On top of that there were quite a few updates that completely broke cross platform play and apparently modifying version string resources could hack around that at the risk of desyncs.
To this day most people ive met that play Civ 6 on Linux swear to me that it runs perfect, so I have no idea what was going on. I've also been told running it via Proton might actually run better but I haven't tried.
Anyway maybe close to a year later, I tried again with Fedora, it ran a bit better, which I imagine to be the work of better updated kernel + system packages, but I had to keep it on the lowest graphics settings to make it barely playable. And this was on a system with a decent mid teir graphics card at the time, more memory than I've ever needed and a Ryzen 9. On top of that there were quite a few updates that completely broke cross platform play and apparently modifying version string resources could hack around that at the risk of desyncs.
To this day most people ive met that play Civ 6 on Linux swear to me that it runs perfect, so I have no idea what was going on. I've also been told running it via Proton might actually run better but I haven't tried.
I didn't notice a difference to be fair.
Though nowadays I have a dual boot and the battery life while running Windows is 4x better than on Debian.
I think Civ probably consumes more CPU/GPU than it really needs to.
Add me to the "it worked OK on Linux" group, though I suspect that a number of drivers could be improved for performance/power reasons. If of use, the laptop I used had an Nvidia 980M which was what I used to play Civ. The fan was blowing hard and the Desktop with a Nvidia 1080 (on Windows) does play faster (I tend to play 'huge' map). It definitely "worked" but maybe less performant.
Though nowadays I have a dual boot and the battery life while running Windows is 4x better than on Debian.
I think Civ probably consumes more CPU/GPU than it really needs to.
Add me to the "it worked OK on Linux" group, though I suspect that a number of drivers could be improved for performance/power reasons. If of use, the laptop I used had an Nvidia 980M which was what I used to play Civ. The fan was blowing hard and the Desktop with a Nvidia 1080 (on Windows) does play faster (I tend to play 'huge' map). It definitely "worked" but maybe less performant.
"Gaming on Linux with GeForce efficiently" looks like difficult task.
> And this was on a system with a decent mid teir graphics card at the time, more memory than I've ever needed and a Ryzen 9.
Out of curiousoity, was this new system also using Nvidia graphics? Or were they otherwise fairly new cards both times?
Out of curiousoity, was this new system also using Nvidia graphics? Or were they otherwise fairly new cards both times?
Both using an Nvidia 2070S
I fear what will happen to DirectX-on-Linux if Oracle vs. Google goes in favor of Oracle.
I've had the same experience with Doom (2016). The most irritating thing was the reduced input latency on Linux, which threw me off for the first few hours. After getting used to it I only boot to Windows for UWP games.
Low input latency irritates you? That's a new one.
I read it in a sense that it's hard to adjust back once muscle memory is set to a certain value.
Doom 2016 and eternal have really significant mouse lag on windows. It’s really hard to get used to. It’s most noticeable if you have recently played an actually responsive FPS recently
Wait, so I tried to fix the mouse lag in Windows for days and the problem was Doom? Fuck.
"Be kind. Don't be snarky. Have curious conversation"
It threw them off for the first few hours, as written. Doesn't mean that low latency in general irritates them, just that they weren't used to it at first.
It threw them off for the first few hours, as written. Doesn't mean that low latency in general irritates them, just that they weren't used to it at first.
I have to agree with yakubin, though, and don't think it was a snarky comment. He just pointed out that it was an odd complaint. Gamers go at great length to reduce input lag on Windows.
You agree that because you're not used to something, that means you're not a fan of that thing in general?
I'm a gamer myself. Upgrading my display makes me slightly off-game myself, until I get used to the new one. Same when getting a new car, where the brakes are way more sensitive than on a old car. Doesn't mean I don't like the brakes to be more sensitive, just means I'm not used to it.
And yes, the first few weeks of sensitive brakes are irritating, just touch the pedal and the car grinds quickly to a full halt. But now I do like it better compared to when you fully press down the pedal and the car slowly stops.
I'm a gamer myself. Upgrading my display makes me slightly off-game myself, until I get used to the new one. Same when getting a new car, where the brakes are way more sensitive than on a old car. Doesn't mean I don't like the brakes to be more sensitive, just means I'm not used to it.
And yes, the first few weeks of sensitive brakes are irritating, just touch the pedal and the car grinds quickly to a full halt. But now I do like it better compared to when you fully press down the pedal and the car slowly stops.
>The most irritating thing was the reduced input latency on Linux
Huh. That's a big competitive advantage in competitive games. Why don't pro CS players use Linux? Is the difference smaller in the games that have been optimized for competitive play?
Huh. That's a big competitive advantage in competitive games. Why don't pro CS players use Linux? Is the difference smaller in the games that have been optimized for competitive play?
I don't know how true this is. Personally I've always noticed significantly more input lag on Linux than Windows for games. I even used to hack on ezquake's Linux port to try and get the input lag down, but the Linux kernel just caused too much latency. This could have changed since then though. You have to realize MS invested significantly in "gaming APIs" like DirectInput, DirectX all tuned to low latency gaming. Linux never really had anything like that. I'd love to see results showing otherwise, I'd far prefer to game in Linux if possible.
It could be that it can vary in multiple areas and depending as well on a lot of different stuff (kernel version, drivers/modules, settings, SW being used, ...).
Personally, I always had the feeling that video was slower on Linux (always used nVidia proprietary drivers in Linux), but when I used to play a bit of e-guitar the audio latency was definitely better in Linux (but as well just for audio there are a lot of settings that play some role - e.g. https://wiki.archlinux.org/index.php/Professional_audio ).
Personally, I always had the feeling that video was slower on Linux (always used nVidia proprietary drivers in Linux), but when I used to play a bit of e-guitar the audio latency was definitely better in Linux (but as well just for audio there are a lot of settings that play some role - e.g. https://wiki.archlinux.org/index.php/Professional_audio ).
I play a lot of stepmania (DDR and stamina), and I have really struggled with audio latency in Linux. And I have spent far too much time on PulseAudio and JACK configuration. Windows, again, is fine with nearly no latency and virtually no configuration required. I have resigned myself to just having a dedicated Windows partition for gaming.
The PCs are provided by the tourney organisers, and it's a marginal benefit really.
Most professional CS is played at 4:3 stretched so the PC is pulling in hundreds of FPS
Most professional CS is played at 4:3 stretched so the PC is pulling in hundreds of FPS
> Most professional CS is played at 4:3 stretched so the PC is pulling in hundreds of FPS
That's unlikely to be true anymore. Even a modestly modern GPU can produce 100's of FPS in CS:GO at 1920x1080 or higher resolutions. Benchmarks for the 3080 were showing 400-500 FPS in CS:GO at 1440p resolutions.
After maybe double your screen refresh rate, all excess FPS don't matter and are effectively wasted. Pro's mostly use 144Hz monitors because 240Hz is indistinguishable[1] - making anything above 288FPS basically a waste (and it's debatable if anything above 144FPS with FreeSync enabled is a waste too).
[1] https://www.youtube.com/watch?v=OX31kZbAXsA
That's unlikely to be true anymore. Even a modestly modern GPU can produce 100's of FPS in CS:GO at 1920x1080 or higher resolutions. Benchmarks for the 3080 were showing 400-500 FPS in CS:GO at 1440p resolutions.
After maybe double your screen refresh rate, all excess FPS don't matter and are effectively wasted. Pro's mostly use 144Hz monitors because 240Hz is indistinguishable[1] - making anything above 288FPS basically a waste (and it's debatable if anything above 144FPS with FreeSync enabled is a waste too).
[1] https://www.youtube.com/watch?v=OX31kZbAXsA
The stretched resolution is because it makes people thicker at the expense of FoV, not performance as per se
> for the first few hours
What were the specs of your machine?
Ryzen 2700X and a MSI GeForce 1070 TI on a 2k screen
They seem to agree that a free OS with an army of enthusiastic geeks ready at all times is at least almost as good for general public (casual gamers) as is MS proprietary garden. If Windows flopped somehow all my friends would have their gaming rigs with most of their games within few days thanks to my experience, and I wouldn't charge more than a few beers.
I still have input lag experience with GTA V on linux despite using new graphics card. The only immediate solution I've found is to play in windowed mode. All other games are playing nicely (ie: Witcher 3, No man's sky).
> Valve is doing god’s work when it comes to Linux gaming. I have played over 40 hours of GTA V without many troubles. The game looks great and performs great. So glad I could get rid of my windows install.
"I would actually prefer if you didn't play GTA V. I mean, I guess it doesn't matter since you're going to hell anyway. But still."
- God
"I would actually prefer if you didn't play GTA V. I mean, I guess it doesn't matter since you're going to hell anyway. But still."
- God
This is nice and all but they need to fix things like alt-tabbing in an out of a game. Many games just crash. I know it sounds dumb but sometimes when organising a game or using discord you need to alt-tab from the game to the chat app. This almost never happens with Windows unless the games are old.
Also performance when streaming via discord or OBS significantly drops the framerate even on games my rig can play at 60FPS (while streaming) at 4k without any problems. Amid Evil for example with start stuttering when streaming in Linux but is 100% fine in Windows.
Many people say these games work fine but in my experience they don't. I am normally running with whatever is the latest version of proton valve is bundling with. Generally though this maybe because UHD is a total mess on Linux.
Also performance when streaming via discord or OBS significantly drops the framerate even on games my rig can play at 60FPS (while streaming) at 4k without any problems. Amid Evil for example with start stuttering when streaming in Linux but is 100% fine in Windows.
Many people say these games work fine but in my experience they don't. I am normally running with whatever is the latest version of proton valve is bundling with. Generally though this maybe because UHD is a total mess on Linux.
> This is nice and all but they need to fix things like alt-tabbing in an out of a game.
This is super hard to get right. It's somewhat wonky on Windows to begin with (we have found plenty of games where it's broken on Windows), and then you have to factor in that X doesn't work the same way, and there are a hundred different window managers, which all work different ways. It should be significantly improved in 5.13, and we're still working on improvements in that area, including in upcoming 5.13 releases.
This is super hard to get right. It's somewhat wonky on Windows to begin with (we have found plenty of games where it's broken on Windows), and then you have to factor in that X doesn't work the same way, and there are a hundred different window managers, which all work different ways. It should be significantly improved in 5.13, and we're still working on improvements in that area, including in upcoming 5.13 releases.
> This is super hard to get right.
Not _really_. The issue is that games are trying to do god-knows-what when they lose focus. In reality, they just need to ignore this happening.
Regular applications handle losing focus just fine, and games would too -- unless you try to do magic funky stuff when you lose focus (my guess is that they do this to work around funky WM issues on window that don't exist on Linux).
Not _really_. The issue is that games are trying to do god-knows-what when they lose focus. In reality, they just need to ignore this happening.
Regular applications handle losing focus just fine, and games would too -- unless you try to do magic funky stuff when you lose focus (my guess is that they do this to work around funky WM issues on window that don't exist on Linux).
First, sure, if games didn't do complex things, it would be easier to support. But they do. So it is hard.
Also, it's much more complicated than that. When running in exclusive fullscreen mode (which almost all fullscreen games did before about 5 years ago), they have to do stuff like restore the original display resolution, tear down their graphics stack, and restore all of that when bringing the window back up. Many games depend on a very particular sequence of window messages during that process, including D3D handling some of those messages on their behalf in certain ways. In the case of non-exclusive or windowed mode games, they may choose to stop reading controller input, stop rendering, stop sending audio, etc. All of that requires correct window notifications in the correct order, and support in Wine for correctly tearing down and restoring all of those things.
And all that is just on the Windows side of the equation, you also need to tear down the Linux graphics stack and manage how X thinks about the windows in a way that the window manager will do the right thing for the user, without doing the /wrong/ thing for the app from the Windows perspective. For example if the WM chooses to resize the window when it requests fullscreen mode, at a time when Windows does not, then we have to ignore those messages, or the game will suddenly be rendering at the wrong size (or worse, infinite loop as the WM and the game fight over the window sizes... yeah, that happened[1]).
It's a nightmare. I've spent months and months on this stuff, and other devs have spent even more. If it was easy to fix, it would be fixed, I promise you :)
[1] https://github.com/ValveSoftware/wine/commit/4f590327ab2028a...
Also, it's much more complicated than that. When running in exclusive fullscreen mode (which almost all fullscreen games did before about 5 years ago), they have to do stuff like restore the original display resolution, tear down their graphics stack, and restore all of that when bringing the window back up. Many games depend on a very particular sequence of window messages during that process, including D3D handling some of those messages on their behalf in certain ways. In the case of non-exclusive or windowed mode games, they may choose to stop reading controller input, stop rendering, stop sending audio, etc. All of that requires correct window notifications in the correct order, and support in Wine for correctly tearing down and restoring all of those things.
And all that is just on the Windows side of the equation, you also need to tear down the Linux graphics stack and manage how X thinks about the windows in a way that the window manager will do the right thing for the user, without doing the /wrong/ thing for the app from the Windows perspective. For example if the WM chooses to resize the window when it requests fullscreen mode, at a time when Windows does not, then we have to ignore those messages, or the game will suddenly be rendering at the wrong size (or worse, infinite loop as the WM and the game fight over the window sizes... yeah, that happened[1]).
It's a nightmare. I've spent months and months on this stuff, and other devs have spent even more. If it was easy to fix, it would be fixed, I promise you :)
[1] https://github.com/ValveSoftware/wine/commit/4f590327ab2028a...
Thank you for doing this kind of work. That commit is funny -- I've read that there's similar stuff in graphics card drivers too :)
> they have to do stuff like restore the original display resolution
This is something that I find incredibly annoying: games handling their own resolution and having their own resolution configuration.
It's like their reinventing something that the OS already provides. Just use the resolution that's configured: if I wanted to change it I'd change it.
Non-native resolutions look awful on LCDs anyway, so apps really shouldn't change it.
Actually though, the easier way to support linux is just to run on windows mode with no chrome -- I can just fullscreen the window myself and that's it.
Games that try to detect screen resolution themselves very often screw up picking the right resolution when you have multiple screens: but again, the problem is they're trying to do too much.
This is something that I find incredibly annoying: games handling their own resolution and having their own resolution configuration.
It's like their reinventing something that the OS already provides. Just use the resolution that's configured: if I wanted to change it I'd change it.
Non-native resolutions look awful on LCDs anyway, so apps really shouldn't change it.
Actually though, the easier way to support linux is just to run on windows mode with no chrome -- I can just fullscreen the window myself and that's it.
Games that try to detect screen resolution themselves very often screw up picking the right resolution when you have multiple screens: but again, the problem is they're trying to do too much.
> Games that try to detect screen resolution themselves very often screw up picking the right resolution when you have multiple screens: but again, the problem is they're trying to do too much.
Even with just one monitor, Unity (native) refuses to believe that 3840x1600 is what I want. Why are hardcoded resolution lists still a thing. At least Unity doesn't change the monitor resolution though, just the internal render resolution.
Even with just one monitor, Unity (native) refuses to believe that 3840x1600 is what I want. Why are hardcoded resolution lists still a thing. At least Unity doesn't change the monitor resolution though, just the internal render resolution.
> Just use the resolution that's configured: if I wanted to change it I'd change it.
So you're saying you'd want to change desktop resolution each time you want to play a performance heavy game?
> Non-native resolutions look awful on LCDs anyway, so apps really shouldn't change it.
So you're saying developers should take away the options that people actively use because you subjectively don't like how it looks on your specific monitor?
So you're saying you'd want to change desktop resolution each time you want to play a performance heavy game?
> Non-native resolutions look awful on LCDs anyway, so apps really shouldn't change it.
So you're saying developers should take away the options that people actively use because you subjectively don't like how it looks on your specific monitor?
> So you're saying you'd want to change desktop resolution each time you want to play a performance heavy game?
Yes, for the Window definitely. If you need to drop the render resolution for perf then the game should upscale at the end (and for fucks sake, handle arbitrary aspect ratios correctly!!!). Personally though, I'd rather wait until I have hardware that can run the game at full resolution.
Yes, for the Window definitely. If you need to drop the render resolution for perf then the game should upscale at the end (and for fucks sake, handle arbitrary aspect ratios correctly!!!). Personally though, I'd rather wait until I have hardware that can run the game at full resolution.
I agree about upscaling the end result, some games do that and I really appreciate it. Lately DLSS took it to the whole other level though
> So you're saying developers should take away the options that people actively use because you subjectively don't like how it looks on your specific monitor?
No, I'm saying they should remove it because they shouldn't aspire to reimplement an OS. I mean, why does a game need to have a panel to configure my hardware, my OS already has that.
Imagine if every single app out there implemented their own "screen resolution" management and settings panel.
It makes no sense.
No, I'm saying they should remove it because they shouldn't aspire to reimplement an OS. I mean, why does a game need to have a panel to configure my hardware, my OS already has that.
Imagine if every single app out there implemented their own "screen resolution" management and settings panel.
It makes no sense.
> every single app out there implemented their own "screen resolution"
Every single app doesn't need to render heavy stuff to fullscreen. I have 2K monitor, but I can't run every game out there with 60-75 FPS at 2K, not without DLSS at least. But I agree with the point made in the sibling comment: they should separate output resolution and render resolution to different options.
Every single app doesn't need to render heavy stuff to fullscreen. I have 2K monitor, but I can't run every game out there with 60-75 FPS at 2K, not without DLSS at least. But I agree with the point made in the sibling comment: they should separate output resolution and render resolution to different options.
I think the point was that for some games it might be better (perfect even) to not tell the game that it has lost focus since on X11 there is no such thing as exclusive fullscreen anyway. Of course that won't work for everything (game won't auto pause, might continue polling for mouse input, ...).
AFAICT Proton already lies to games about the fullscreen resolution and silently upscales the result instead changing the monitor resolution (which I think might be the single most awesome thing Proton adds) so this isn't unprecedented.
AFAICT Proton already lies to games about the fullscreen resolution and silently upscales the result instead changing the monitor resolution (which I think might be the single most awesome thing Proton adds) so this isn't unprecedented.
Since its all emulated why even tell the game its alt tabbed in the first place? Just keep it thinking nothing changed, its not like games do special stuff when in the background.
We investigated that briefly. It's not as easy as it sounds, and even if it was, some games do useful things when they lose focus (e.g. auto pause the game, stop sending audio). We decided it wasn't worth pursuing.
From one engineer to another: I'm sorry you keep having to deal with people who haven't spent a single minute working on this problem second-guessing your work. I get the same thing regularly and it can be very frustrating.
As you noted: if the solution were so trivial it would have been done and shipped already.
As you noted: if the solution were so trivial it would have been done and shipped already.
Hahaha! Nah, it's fine. Their suggestion was a good one; like I said, we did consider doing it. It's fun to talk about this stuff here on HN because the discussion is usually sensible. You should see the dumb crap they say on Reddit.
You can work on something forever and still have others provide new insights. Feedback is not an attack, even if you have already considered that option (and even then there might be crucial details that could change things).
Would it be worth it to make that as an option, perhaps a command line option like PROTON_ALWAYS_FOCUSED=1?
The thing is (as a mostly windows gamer here) it is not consistent in windows really either. Then on top of that many of the companies that made these games went basically defunct years ago and some publisher is just selling them and cutting a check to some other company that is a shell corp for something else. You are correct on what should happen to the game. But some programs do need to react to lose focus. So for it to 'ignore' it there would need to be a setting for it (and per program). Which could even cause side effects in that game because they just plain got it wrong.
I have had in the past month seen black screen on return. No controls after return. Does not tab out at all. There are other variations. Most games do work. But some dont. My wife plays dont starve quite a bit and that game is kind of flakey in its external behavior (once in game you are fine). One bug she is dealing with is in some cases it takes 30+ mins to get in game with new settings on a fairly beefy new computer.
I have had in the past month seen black screen on return. No controls after return. Does not tab out at all. There are other variations. Most games do work. But some dont. My wife plays dont starve quite a bit and that game is kind of flakey in its external behavior (once in game you are fine). One bug she is dealing with is in some cases it takes 30+ mins to get in game with new settings on a fairly beefy new computer.
From my experience most games work fine when switching away. However I know that Don't Starve Together and some other games really freak out. (I've been lucky enough not to see any crashes though)
What I have found is that running games under Wayland (via XWayland) makes a lot of games behave better. I don't know exactly why this is but I suspect they are trying to manipulate a bunch of settings like fullscreen/input grabbing/display resolution which just get ignored by Wayland. So basically the extra restrictions of Wayland stop them from shooting themselves in the foot.
On the downside my NVIDIA GPU can't be used on Wayland...
What I have found is that running games under Wayland (via XWayland) makes a lot of games behave better. I don't know exactly why this is but I suspect they are trying to manipulate a bunch of settings like fullscreen/input grabbing/display resolution which just get ignored by Wayland. So basically the extra restrictions of Wayland stop them from shooting themselves in the foot.
On the downside my NVIDIA GPU can't be used on Wayland...
Haven't tried it myself since I switched away from NVIDIA, but supposedly initial support for the NVIDIA specific interface was added in KDE 5.16 and Gnome 3.31 both released last year might not be available if you are on a LTS distro.
For me the problem is that I have an Optimus laptop (Intel primary GPU with NVIDIA discrete card) which as far as I can tell has no published timeline for driver support, if it will ever come.
It doesn't work. I've tried it on Arch and I have to force gnome to use X via a GDM environment variable IIRC.
I think Xwayland GPU acceleration won't work with NVIDIA still, though.
Yeah. It's not just alt-tabbing, merely losing focus.
I've a second monitor where I run discord (and lots of other shit), so if I even focus on it for a second: the game is dead.
Generally, you can work around this by configuring wine to use a virtual desktop. The game never picks up its focus-loss.
I've a second monitor where I run discord (and lots of other shit), so if I even focus on it for a second: the game is dead.
Generally, you can work around this by configuring wine to use a virtual desktop. The game never picks up its focus-loss.
Well you would have been right 6 months ago, but right now it's absolutely not an issue any more. Even pointer capture works right. Even on multiple monitors. Try it again with a recent Proton.
You can thank Zhiyi Zhang for working on that for the past year or two[1]. I'm very happy to hear it's working well for you.
[1] https://source.winehq.org/git/wine.git/?a=search&h=HEAD&st=a...
[1] https://source.winehq.org/git/wine.git/?a=search&h=HEAD&st=a...
Excellent work, I was really impressed.
I don't play many non-native games, but I have had many games on Windows crash or behave badly when alt-tabbing. Personally I've found that aspect significantly better on Linux.
There can sometimes be issues with native games too, altough I agree that the situaton is better (mostly due to not having exclusive fullscreen in the first place). One game I came across was letterboxed on my resolution but would never re-pain the black borders (after initially clearing them). This worked fine until Alt-tabbing out and back in where (with DRI3) the backing memory for the backbuffer would get reallocated and those black borders would now show garbage.
This is a workaround, but I use Discord on my phone to avoid having to go afk in games. It works almost as well as the desktop client, for the most part.
Quick perusal of the extension would indicate that it’s main purpose is to help emulate dx12 more efficiently.
DX12 doesn’t have descriptorsets like Vulkan. It has descriptorheaps that are bit different. This extension basically makes them quite similar. First of all the descriptors can be stored into the same place (In Vulkan the descriptors are strongly typed.). With this an image or buffer etc can use same descriptor in a set, like DX12. In addition the CPU only heap is exposed in this, allowing the platform to directly implement DX12 heaps with desc sets.
Don’t really think this would help with DX11 at all. But it would make the mess that is DX12 binding model more tolerable to emulate.
Still not sure how would they emulate the root parameters to their full extent though.
DX12 doesn’t have descriptorsets like Vulkan. It has descriptorheaps that are bit different. This extension basically makes them quite similar. First of all the descriptors can be stored into the same place (In Vulkan the descriptors are strongly typed.). With this an image or buffer etc can use same descriptor in a set, like DX12. In addition the CPU only heap is exposed in this, allowing the platform to directly implement DX12 heaps with desc sets.
Don’t really think this would help with DX11 at all. But it would make the mess that is DX12 binding model more tolerable to emulate.
Still not sure how would they emulate the root parameters to their full extent though.
Despite all the comments here stating the opposite, steam has been a home run for me on linux. It worked flawlessly on all my machines and it continues to do so.
How do we deserve Valve?
Okay: Any possibility to support their open source work? (except of using steam)
Okay: Any possibility to support their open source work? (except of using steam)
> How do we deserve Valve?
Simple, private ownership structure stemming from bootstrapping. Any presence of external equity or (worse) publicly traded shares would make it impossible to ever consider the money printing machine that the steam store is "good enough" for now and focus on long term strategy instead. Perhaps even allowing certain forms of "benevolence". Companies with private, noninstitutional owners can be infinitely greedy as well, but they don't have to be. Contrast this with publicly traded: there, if there is any reason to believe that more could be earned, someone ruthless/optimistic enough to believe this will bid more for ownership than those who don't and eventually the company is forced to go the ruthless path due to it's ownership structure.
If there were shares traded of a goose that lays golden eggs, the shares would inevitably end up being owned by those who believe that cutting it open yields more than waiting for the next egg. Apparently Newell isn't prone to cutting up the goose.
Simple, private ownership structure stemming from bootstrapping. Any presence of external equity or (worse) publicly traded shares would make it impossible to ever consider the money printing machine that the steam store is "good enough" for now and focus on long term strategy instead. Perhaps even allowing certain forms of "benevolence". Companies with private, noninstitutional owners can be infinitely greedy as well, but they don't have to be. Contrast this with publicly traded: there, if there is any reason to believe that more could be earned, someone ruthless/optimistic enough to believe this will bid more for ownership than those who don't and eventually the company is forced to go the ruthless path due to it's ownership structure.
If there were shares traded of a goose that lays golden eggs, the shares would inevitably end up being owned by those who believe that cutting it open yields more than waiting for the next egg. Apparently Newell isn't prone to cutting up the goose.
There are plenty of public companies, such as intel and google, that manage to pursue a long term strategy, to commodotize their complement: https://www.gwern.net/Complement
Google's habit of killing any product that isn't search or Gmail suggests otherwise
Yes and Intel's example is also not good either.
Hire open source consulting companies like Collabora, Igalia, Bootlin etc to work on Linux/graphics stuff. IIRC Valve is doing this work via Collabora. I note that both Igalia and Bootlin have done crowdfunding campaigns to support their Linux, graphics and web work:
http://open-prioritization.igalia.com/ https://www.igalia.com/2020/09/28/Open-Prioritization-Experi... https://bootlin.com/blog/tag/crowdfunding/ https://github.com/fossjobs/fossjobs/wiki/Resources#employer...
http://open-prioritization.igalia.com/ https://www.igalia.com/2020/09/28/Open-Prioritization-Experi... https://bootlin.com/blog/tag/crowdfunding/ https://github.com/fossjobs/fossjobs/wiki/Resources#employer...
As a gamer: Buy their games
As an industry: Follow their lead and be prepared to pay for the software you rely on - there are some really clever people out there, for a company like valve this is pocket change but someone still needs to have the balls to do it.
As an industry: Follow their lead and be prepared to pay for the software you rely on - there are some really clever people out there, for a company like valve this is pocket change but someone still needs to have the balls to do it.
Buy their games without steam.
I'm thankfully for the native games from Valve on Linux. And also for improving gaming on Linux in general. Steam? Steam itself is not necessary and is just another system to lure users and developers into a Vendor Lock-In. Everything useful it provides should be part of libraries. In a better world - we would use a package manager or Flatpak to install games.
I'm sick of the software industry, every big company tries to lock you in. Microsoft (historically with contracts, incompatiblity and UWP and now Cloud), Apple (AppStore and of course incompatibility), Google (Cloud and PlayStore...and making everything else then Google Services a pain) and EPIC (Games Store).
No other industry has managed to be so awful than software industry. You can drive another brand of car than anybody else in your town and be fine with it, as long you get support (spare parts). But software? Hell no! Your choice is either pain through being in a minority or pain through living without control upon your your software, unsteadiness, insecurity, high costs...
I'm sick of the software industry, every big company tries to lock you in. Microsoft (historically with contracts, incompatiblity and UWP and now Cloud), Apple (AppStore and of course incompatibility), Google (Cloud and PlayStore...and making everything else then Google Services a pain) and EPIC (Games Store).
No other industry has managed to be so awful than software industry. You can drive another brand of car than anybody else in your town and be fine with it, as long you get support (spare parts). But software? Hell no! Your choice is either pain through being in a minority or pain through living without control upon your your software, unsteadiness, insecurity, high costs...
> Steam itself is not necessary and is just another system to lure users and developers into a Vendor Lock-In
This ignores the history of how Steam came about in the first place. The PC gaming industry was basically dying because physical distribution was expensive, which made the games expensive too, so a lot of users just pirated games (by downloading them from the internet) because it was easier. Valve recognized that piracy was a symptom of a service problem and set out to create the convenient service experience of piracy in legitimate form. It was actually widely hated at first because people assumed malevolence, but over time Valve has proved their good intentions with the platform. They helped kick off the indy explosion with the Potato Sack, they allow developers to sell Steam keys on other stores without giving Valve a cut, they never ask for exclusivity, and despite what many internet whiners complain about they actually try pretty hard to have worthwhile recommendation and review systems.
> Everything useful it provides should be part of libraries. In a better world - we would use a package manager or Flatpak to install games.
This is basically already the case. Steam is the manager, and it also provides the libraries for its functionality (DRM, workshop, achievements, etc) that are entirely optional. There are games on Steam that don't use any of that and you can copy them to a system without Steam and they run fine (BallisticNG was like this last I checked). Hell, as EA and Ubisoft proved you can even install and run your own alternative client as part of your game you sell on Steam (though thankfully the store now warns users about this behavior).
This ignores the history of how Steam came about in the first place. The PC gaming industry was basically dying because physical distribution was expensive, which made the games expensive too, so a lot of users just pirated games (by downloading them from the internet) because it was easier. Valve recognized that piracy was a symptom of a service problem and set out to create the convenient service experience of piracy in legitimate form. It was actually widely hated at first because people assumed malevolence, but over time Valve has proved their good intentions with the platform. They helped kick off the indy explosion with the Potato Sack, they allow developers to sell Steam keys on other stores without giving Valve a cut, they never ask for exclusivity, and despite what many internet whiners complain about they actually try pretty hard to have worthwhile recommendation and review systems.
> Everything useful it provides should be part of libraries. In a better world - we would use a package manager or Flatpak to install games.
This is basically already the case. Steam is the manager, and it also provides the libraries for its functionality (DRM, workshop, achievements, etc) that are entirely optional. There are games on Steam that don't use any of that and you can copy them to a system without Steam and they run fine (BallisticNG was like this last I checked). Hell, as EA and Ubisoft proved you can even install and run your own alternative client as part of your game you sell on Steam (though thankfully the store now warns users about this behavior).
Heh, are you saying that Steam could have been (or is) the equivalent of Snap on Ubuntu?
https://snapcraft.io/about
https://snapcraft.io/about
Yet here I am, playing PC games while keeping my PC Steam free.
I'm not sure what point you're trying to make here. Of course you can play games without Steam. But I think it is disingenuous to characterize Steam as "just another system to lure users and developers into a Vendor Lock-In" when Valve has seemingly not put any effort whatsoever into locking in anyone despite their unquestioned market dominance.
They recently stopped developers promoting on steam, sale of their game on other platforms. Makes a lot of sense and if the battle with epic games gets worse we might see lock in..
Fortnite changed steam's dominance. Epic games is buying out a lot of games to offer on their store and they have the cash to burn on it. Who knows where all the fortnite fans will be in 5yrs, epic or steam.
Fortnite changed steam's dominance. Epic games is buying out a lot of games to offer on their store and they have the cash to burn on it. Who knows where all the fortnite fans will be in 5yrs, epic or steam.
> They recently stopped developers promoting on steam, sale of their game on other platforms.
Hard to blame them for a stance of "you can't use our storefront to advertise other storefronts" though.
Epic is doing the things it is doing precisely because Steam is so ludicrously dominant. I'd argue that they haven't been successful at usurping that dominance yet. They are still very much playing catch-up.
Hard to blame them for a stance of "you can't use our storefront to advertise other storefronts" though.
Epic is doing the things it is doing precisely because Steam is so ludicrously dominant. I'd argue that they haven't been successful at usurping that dominance yet. They are still very much playing catch-up.
I honestly don't think they are aiming to take over Steam. There's a lot of features they could implement with their cash that would match Steam's store.
They prefer their churn and burn, buying out games and giving them for reduced prices. It makes little sense unless it is seen as a very long term play.
They prefer their churn and burn, buying out games and giving them for reduced prices. It makes little sense unless it is seen as a very long term play.
"Unquestioned market dominance.", not really.
You disagree that Steam is the market leader in PC game distribution?
I definitely do. Any independent market reports from IGDA or similar to prove otherwise?
Valve own marketing material doesn't count.
Valve own marketing material doesn't count.
https://www.gamesindustry.biz/articles/2017-12-20-gamesindus...
The above article estimates the PC gaming industry sold around 32.3 billion in 2017, although from [0]:
> If you throw out revenue for packaged retail titles and browser games, that leaves the dedicated digital PC game business with a total value of $23.9 billion – and that number includes DLC, which the Steam estimate does not.
> If the numbers are right, that means Valve own at least 18% of their specific market
This is by no means exact, but 18% for PC gaming is huge and, given that these are global numbers, probably doesn't account for the PC games market in China.
0: https://www.pcgamesn.com/steam-revenue-2017
1: https://galyonk.in/steam-in-2017-129c0e6be260
The above article estimates the PC gaming industry sold around 32.3 billion in 2017, although from [0]:
> If you throw out revenue for packaged retail titles and browser games, that leaves the dedicated digital PC game business with a total value of $23.9 billion – and that number includes DLC, which the Steam estimate does not.
> If the numbers are right, that means Valve own at least 18% of their specific market
This is by no means exact, but 18% for PC gaming is huge and, given that these are global numbers, probably doesn't account for the PC games market in China.
0: https://www.pcgamesn.com/steam-revenue-2017
1: https://galyonk.in/steam-in-2017-129c0e6be260
While 18% is a big number it definitely isn't "Unquestioned market dominance.".
I think that that software industry philosophy now applies to many other things. I guess because most things now run software, from cars to farmers milk tanks. But it's probably not the only reason.
I agree with you on everything except for Steam. It is the only launcher / store I have installed because it legitimately adds value to the games I play. Specifically Big Picture and In Home Streaming let me play my games on any other device I want, and that's done a lot of mileage for me in playing games like Final Fantasy XIV on the Nintendo Switch, or even on my old laptop sitting in bed.
for those who wants to see benchmarks:
RDR 2 (Read Dead Redemption) on linux vs windows
https://www.youtube.com/watch?v=6RfJoH1N6IQ
I have played several windows only games on my linux computer in the last couple of weeks and it works great. It's very, very impressive.
Neat, which brand of GPU?
AMD, most likely. There's a lot of benchmark comparisons between Linux and Windows here [1].
[1] https://flightlessmango.com/
[1] https://flightlessmango.com/
I run nVidia on Ubuntu 20.04 with proprietary drivers and few (gaming) problems.
Most game engines work with some kind of abstraction to unify access to the underlying graphics APIs such as D3D, DX12, OpenGL, Vulkan and Metal (for example in Unity there's GraphicsDevice). Does anyone know if there's any work being done to create an open source abstraction like that? It would be neat if it were possible for open source games and game engines to share the work being done to ease cross-platform development.
OpenGL/Vulkan are open source, multi-platform abstraction layers. Of course, the graphics API isn't the only thing you have to get to work on multiple platforms. There's also the sound stack, networking, window management, and so forth.
I think what you're getting at is some kind of all-in-one platform that abstracts away all of those lower level interfaces. In that case, that's basically what Unity is. Unity (and other cross-platform engines) do abstract away the metal in an open source, cross-platform set of APIs/tooling.
If you're more interested in application development, as opposed to videogame development, there's toolkits like QT and VM-based environments like Java and Electron. The efficaciousness of these approaches do vary, however. Java UIs are famously ugly, due to how poorly they integrate with the host OS, Electron UIs are famously slow, due to literally being standalone web browser instances, and QT UIs are famously finicky, due to trying to abstract a lot less than the other approaches.
I think what you're getting at is some kind of all-in-one platform that abstracts away all of those lower level interfaces. In that case, that's basically what Unity is. Unity (and other cross-platform engines) do abstract away the metal in an open source, cross-platform set of APIs/tooling.
If you're more interested in application development, as opposed to videogame development, there's toolkits like QT and VM-based environments like Java and Electron. The efficaciousness of these approaches do vary, however. Java UIs are famously ugly, due to how poorly they integrate with the host OS, Electron UIs are famously slow, due to literally being standalone web browser instances, and QT UIs are famously finicky, due to trying to abstract a lot less than the other approaches.
Right now that cross platform abstraction layer is the Web.
- https://get.webgl.org/webgl2/
- https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_...
- https://webrtc.org/
- https://get.webgl.org/webgl2/
- https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_...
- https://webrtc.org/
This is true and works for a lot of things (I love the web and publish a lot of web apps). However there is currently a very significant performance penalty both due to the available graphics APIs and due to WASM or JS vs native CPU performance. So for games with demanding graphics the web isn't that attractive of a target.
I didn't say it was the highest perf. Just that it is that abstraction layer that runs everywhere.
I absolutely agree. It's the best way to get an app out that works everywhere.
In fact, I actually really wish we could collectively work out some kind of shared container environment for such apps to run more "natively". Something like Electron, but shared between many applications and a little more loosey-goosey in terms of hacking on top of it. Essentially, I want emacs for webapps lol
In fact, I actually really wish we could collectively work out some kind of shared container environment for such apps to run more "natively". Something like Electron, but shared between many applications and a little more loosey-goosey in terms of hacking on top of it. Essentially, I want emacs for webapps lol
Not being snarky, but I believe that format is html.
No snark taken. My counterpoint here would be that HTML is a markup language and that the "equivalent to emacs" would be the web browser itself. My issue with that potential position is that the web is implicitly untrusted.
That's why developers even deign to put up with Electron in the first place, because their app can run with more permissions and, thus, offer better host integration (i.e. "nativeness").
Of course, everyone loves to hate Electron. Who wants to run 6 different Chromium instances? Nobody, apparently! I'm not the first wise guy to suggest a single-instance approach that combines the performance wins of a shared browser instance with the trust of an Electron application. It's painfully obvious that there's a golden medium here, but, of course, if it were an easy problem to solve, it would already be solved!
That's why developers even deign to put up with Electron in the first place, because their app can run with more permissions and, thus, offer better host integration (i.e. "nativeness").
Of course, everyone loves to hate Electron. Who wants to run 6 different Chromium instances? Nobody, apparently! I'm not the first wise guy to suggest a single-instance approach that combines the performance wins of a shared browser instance with the trust of an Electron application. It's painfully obvious that there's a golden medium here, but, of course, if it were an easy problem to solve, it would already be solved!
I believe bfgx[0] is similar to what you're describing. It's been around since before the Vulkan/DX12/Metal era so the abstractions are more similar to OpenGL/DX11 where you don't have concepts like command buffers and command queues etc, which might be a turn off.
Big open source projects still seem to roll their own solution for this, which I imagine is both for historical reasons but also because there might be a fear that using a library like this could leave your hands tied when you need to do some API-specific workaround.
0. https://github.com/bkaradzic/bgfx
Big open source projects still seem to roll their own solution for this, which I imagine is both for historical reasons but also because there might be a fear that using a library like this could leave your hands tied when you need to do some API-specific workaround.
0. https://github.com/bkaradzic/bgfx
After searching some more, I came across this: https://github.com/ConfettiFX/The-Forge
It sounds a bit more heavyweight than what I was getting at, but it still makes me hopeful that there's a future for something like this.
It sounds a bit more heavyweight than what I was getting at, but it still makes me hopeful that there's a future for something like this.
Shouldn't this be a priority even for other gaming platforms?
Imagine all the progress we made on development tools and containerization ported to the game development environment.
I think it could be a huge step forward!
Imagine all the progress we made on development tools and containerization ported to the game development environment.
I think it could be a huge step forward!
I have a huge (already downloaded) library on Steam Windows.
Does anyone know how to "share" the game resources so that the Linux version only download the executable/runner?
Does anyone know how to "share" the game resources so that the Linux version only download the executable/runner?
Watch out, the suggestions in the other replies are hazardous. It's possible to add your windows Steam library to a Linux client, after mounting the windows partition, and this will work fine most of the time(so you could still give it a try). However, you're also likely to run into annoying-to-debug issues due to Linux's mishandling of ntfs.
I've eventually given up on this method, and I'm not sure if there is a good solution. I ended up just buying more hard drive and selectively installing the games I want in linux partitions.
I've eventually given up on this method, and I'm not sure if there is a good solution. I ended up just buying more hard drive and selectively installing the games I want in linux partitions.
Maybe share an exFAT partition? Is the support of exFAT on Linux any good now?
If you're intending to use Proton, FAT filesystems aren't recommended as they don't support symlinks or certain important filename characters like ':'.
I don't understand the last part. : is not a supported character on Windows at all. Windows games should not expect to be able to access file names that contain it.
Yes it is, the colon is NTFS syntax for alternate data streams.
https://docs.microsoft.com/en-us/sysinternals/downloads/stre...
https://docs.microsoft.com/en-us/sysinternals/downloads/stre...
1) The colon is part of the syntax to access alternate data streams, i.e., it is not an actual part of the file name. In the same way that \ is not a valid character in file names, but it is used to delimit folders.
2) I seriously doubt any game uses alternate data streams for anything.
2) I seriously doubt any game uses alternate data streams for anything.
There is 'native' support in Kernel 5.4 which doesn't require any extra drivers. The other driver I've used before that is userspace so can be a bit slower but works fine.
You can avoid much of the download suck by making a (steam client) backup of your games from the windows system, then restoring that backup onto the linux system.
AFAIK that will avoid re-download of most of the shared assets where possible. You may have to start the install of things on the new steam client, then pause them, before it will let you restore the backups.
AFAIK that will avoid re-download of most of the shared assets where possible. You may have to start the install of things on the new steam client, then pause them, before it will let you restore the backups.
I just want to chime in and say you probably don't want to do this. Steam on linux can technically work with NTFS drives, but I've only had success running games that are linux-native. With anything that uses wine behind the scenes there are problems relating to file permissions.
I gave up and just created an ext4 partition and things got a lot more stable.
I gave up and just created an ext4 partition and things got a lot more stable.
I haven't tried this myself, but you might be able to add the existing directory to Steam on the Linux side and Steam might be smart enough to download exactly what it needs, since all the assets are already present.
At least on Windows you can add an existing steamapps directory on the download settings page. If you can add custom library locations on Linux, I'd probably try making a copy of my Windows steamapp library, adding that directory in the Linux client and running repair for all individual games. That will at least save you from having to download everything.
I really really wouldn't trust a game across Linux to windows unless it was read only.
Probably possible, but when you have (for example) the DCS installer starting itself and possibly wiping the drive, I don't trust half the games I own to play nice enough to behave in a weird setting
Probably possible, but when you have (for example) the DCS installer starting itself and possibly wiping the drive, I don't trust half the games I own to play nice enough to behave in a weird setting
It's a really good idea to just install it on each partition, but good luck...
if you can mount the Windows partition under Linux (ntfs) you may be able to link your Steam Library under the Steam Linux client, but you have to know that some compatibility issues will arise with non-Linux partitions.
Note that as the character ':' is reserved in NTFS, Proton cannot create its wineprefix in the NTFS steamapps/compatdata directory. To solve this, you need to symlink that folder to a filesystem that support filename with the character ':', such as ext4.
More info here:
https://github.com/ValveSoftware/Proton/wiki/Using-a-NTFS-di...
https://github.com/ValveSoftware/Proton/issues/82#issuecomme...
Windows and Linux can share steamapps directory though, I've tried this by installing my games to an external SSD with NTFS filesystem and I can play the games under Proton on my PC and Windows at another PC. I'm not sure whether this will work for games that have native Linux version though
https://github.com/ValveSoftware/Proton/wiki/Using-a-NTFS-di...
https://github.com/ValveSoftware/Proton/issues/82#issuecomme...
Windows and Linux can share steamapps directory though, I've tried this by installing my games to an external SSD with NTFS filesystem and I can play the games under Proton on my PC and Windows at another PC. I'm not sure whether this will work for games that have native Linux version though
I'm having the same issue on my PC. It runs multiple OSes and I'd like to share the Steam library. I've settled for Ext4FS, which works on all the Linux distributions, but not on Windows. I wonder, has anyone tried to get this to work? There's at least 3 options: Ext4FS (Ext3/Ext2), NTFS, and Btrfs (which has a Windows driver as well).
With enough perseverance ExtFAT and UDF might work too.
>I'm not sure whether this will work for games that have native Linux version though
When you switch OS it will reinstall the version for that operating system. At least that was the case when I tried about 18 months ago
When you switch OS it will reinstall the version for that operating system. At least that was the case when I tried about 18 months ago
Good progress. Too bad many games still come out using DX12 today instead of Vulkan, so such translation is needed.
MS is still its old '90s lock-in self when it comes to gaming and Vulkan adoption. So efforts like this is a great way to break that lock-in and it helps to gradually increase Linux gaming user base which eventually will help break the catch 22 deadlock of publishers ignoring Linux.
MS is still its old '90s lock-in self when it comes to gaming and Vulkan adoption. So efforts like this is a great way to break that lock-in and it helps to gradually increase Linux gaming user base which eventually will help break the catch 22 deadlock of publishers ignoring Linux.
I really hope I can play all my games on linux one day. Right now I only play Age of empires 2 definitive edition, anybody knows if i can play it ranked on linux?
Age of Empires 2 is rated Platinum on ProtonDB [0]. This should mean it will work flawlessly without any tweaking.
[0] https://protondb.com/app/221380
[0] https://protondb.com/app/221380
I've played some online ranked in Linux with DE. On some of the older patches I had random crashes upon reaching castle age so I'm currently sticking to windows though.
I have all versions of AoE in my steam library, currently none of those are playable on Linux. Not surprising since the games are developed by Microsoft.
You could try Wine, I haven't tried that.
You could try Wine, I haven't tried that.
From ProtonDB:
Age of Empires 2 (2013) - Platinum
Age of Empires 3 - Gold
Age of Empires 2 - Gold
Age of Empires - Gold
https://protondb.com/search?q=age%20of%20empires
Age of Empires 2 (2013) - Platinum
Age of Empires 3 - Gold
Age of Empires 2 - Gold
Age of Empires - Gold
https://protondb.com/search?q=age%20of%20empires
So not definitive edition ? :(
Apparently the 'Age of Empires 2' from that listing is the definitive edition. It's rated Gold so should work in most cases.
https://www.protondb.com/app/813780
https://www.protondb.com/app/813780
I've played 4v4 ranked on DE with friends without any (WINE-specific) crashes. This was about 6 months ago, so it's likely things are even more stable now.
Haha, here I was thinking that I had 'all versions'.
I have in my library:
AoE
AoE 2
AoE 2 HD
AoE 2 Definitive Edition
None of them show up in my Linux steam library.
I have in my library:
AoE
AoE 2
AoE 2 HD
AoE 2 Definitive Edition
None of them show up in my Linux steam library.
Ah, you'll need to enable proton for all games in settings
Steam -> Settings -> Steam Play and tick "Enable Steam Play for all titles"
Steam -> Settings -> Steam Play and tick "Enable Steam Play for all titles"
I tested the other day on ubuntu 18.04. yes, proton can run crysis. But the in game videos are real laggy. That's a pretty great feat in itself.
It's cool seeing the tech develop to run D3D/OpenGL on Vulkan/DX12/Metal, moving a lot of code out of drivers and in to libraries. But in the long term apps should all end up using Vulkan/DX12/Metal themselves directly (or modern derivatives) - so there won't be many uses for the old legacy D3D/OpenGL stacks left, so these libraries will probably fall out of use too. So, nice for the short/medium term, but probably no longer relevant in the long term.
> But in the long term apps should all end up using Vulkan/DX12/Metal themselves directly
In terms of "a typical 3d app writes directly to the API", they really shouldn't.
The fundamental shift between DX12/Vk and the earlier APIs is that the old graphics APIs were fundamentally about graphics, in the sense that they described a specific way to draw graphics, and then in conjunction with hardware translated that into something that ran well. Originally, there were many very different ways this was done. Over time the hardware implementations all converged towards a common form, and game developers found themselves not really coding against the old APIs as designed, but twisting it's use into something that translated into what they wanted on the actual hardware. (That they knew and understood because of the consoles that just let the devs target the same or very similar hardware directly without a translation layer on top of it.)
DX12/Vk then approaches the API design from a completely different perspective: They are designed to provide an efficient interface to the functionality that is available in hardware. Much of this is graphics-specific, simply because the hardware is meant to run graphics, but in a very real way the API isn't about the graphics, it's about the hardware. Vk doesn't have the kind of simple graphics pipeline that OpenGL devs are used to, because it's outside the context of the API. You, the developer, are supposed to make your own pipeline, out of the pieces of hardware-supported operations that the API exposes.
Which brings this back to my point: The typical game dev has no interest or need to learn DX12/Vk, because they fundamentally do not provide what the devs need or want. Instead, game devs should largely build their work on top of an actual graphics pipeline. Right now, most devs get that pipeline out of the large 3rd-party game engines (UE, Unity), but if you are not using those, OpenGL or DX11 is not a bad choice, and a lot of studios still do that, and probably will for a very long time yet.
Hopefully over time someone will design a good separate graphics pipeline that runs on DX12/Vk, that is designed purely to be a good abstraction for graphics, and will do that well enough that it will replace most use of the old APIs. However, this will take a very long time, simply because of the human factors. (I already know DX11/OGL, why would I learn something new?) But even when it does, D3D/OpenGL will not be replaced by DX12/Vk, they will be replaced by a new translation layer that sits on top of it and is an analogue of these translation layers being built now.
In terms of "a typical 3d app writes directly to the API", they really shouldn't.
The fundamental shift between DX12/Vk and the earlier APIs is that the old graphics APIs were fundamentally about graphics, in the sense that they described a specific way to draw graphics, and then in conjunction with hardware translated that into something that ran well. Originally, there were many very different ways this was done. Over time the hardware implementations all converged towards a common form, and game developers found themselves not really coding against the old APIs as designed, but twisting it's use into something that translated into what they wanted on the actual hardware. (That they knew and understood because of the consoles that just let the devs target the same or very similar hardware directly without a translation layer on top of it.)
DX12/Vk then approaches the API design from a completely different perspective: They are designed to provide an efficient interface to the functionality that is available in hardware. Much of this is graphics-specific, simply because the hardware is meant to run graphics, but in a very real way the API isn't about the graphics, it's about the hardware. Vk doesn't have the kind of simple graphics pipeline that OpenGL devs are used to, because it's outside the context of the API. You, the developer, are supposed to make your own pipeline, out of the pieces of hardware-supported operations that the API exposes.
Which brings this back to my point: The typical game dev has no interest or need to learn DX12/Vk, because they fundamentally do not provide what the devs need or want. Instead, game devs should largely build their work on top of an actual graphics pipeline. Right now, most devs get that pipeline out of the large 3rd-party game engines (UE, Unity), but if you are not using those, OpenGL or DX11 is not a bad choice, and a lot of studios still do that, and probably will for a very long time yet.
Hopefully over time someone will design a good separate graphics pipeline that runs on DX12/Vk, that is designed purely to be a good abstraction for graphics, and will do that well enough that it will replace most use of the old APIs. However, this will take a very long time, simply because of the human factors. (I already know DX11/OGL, why would I learn something new?) But even when it does, D3D/OpenGL will not be replaced by DX12/Vk, they will be replaced by a new translation layer that sits on top of it and is an analogue of these translation layers being built now.
To add to this: we've already seen high-budget games with worse performance on Direct3D 12 than on Direct3D 11. Making good use of the new APIs is no small task.
The last part is what I was referring to by "modern derivatives". OpenGL is widely regarded to have a poor API. If you want a higher level API, wouldn't you want a new modern layer with a nicer API instead? How long will technologies like OpenGL last just because people have already learnt them? Surely eventually we will switch over to better alternatives?
That has been covered by middleware for years, which is another reason why most professional studios don't care about 3D API portability as much as FOSS crowd thinks.
Keeping older D3D and GL versions alive via emulation layers on top of modern APIs totally makes sense also for the future. Only few applications and games actually benefit from the new APIs, but the new APIs require a lot more work and detailed knowledge of what's going on under the hood (with the exception of Metal vs GL of course, Metal is a lot nicer to work with than GL; but if you compare D3D11 to Vulkan or D3D12, then D3D11 definitely is the more "ergonomic" API - at least for rendering traditional triangle geometry).
Apart from other excellent answers, there will also always be a need to run legacy software. Surely we don't want to lose the ability to play old games, for instance?
I don't believe opengl is going anywhere. It's still heavily embedded in modern gaming everywhere. If anything a translation layer from opengl to vulkan would be the direction.
Does Valve have a vested interest in helping gaming on Linux? What do they get out of it?
Or are they a generous corporate machine doing it out the goodness of their heart?
Or are they a generous corporate machine doing it out the goodness of their heart?
I've read that Valve was worried about Windows Store eating their lunch (i.e. creating a walled garden around gaming on windows platform). So Valve started investing heavily into gaming on Linux as a hedge.
Linux is effectively valves insurance policy against microsoft going back to the good old days.
Maybe it's profitable already? 0.8-1% of Steam's userbase is not a small number.
Steam has a vested interested on Linux ever since Microsoft introduced the Microsoft Store.
Is this support to linux related to gaming on the cloud (where servers are mostly linux)? Maybe that's the interest and not so much the linux users...
It's part of Valve's hedge against Windows. Basically, Valve is making sure they (and no other developer or publisher) end up in an 'Epic vs {Apple,Google}' situation.
Valve: invest in technologies that weaken their dependency on third parties.
Epic: sue the third parties they depend on and complain about them loudly on Twitter.
Valve: invest in technologies that weaken their dependency on third parties.
Epic: sue the third parties they depend on and complain about them loudly on Twitter.
Interesting point of view, and it's true that by removing that dependency their position is a bit stronger. I didn't realize about it, thanks for sharing!
Most games will never work on Linux since anti cheat on the platform is infeasible.
This is an absurd comment for two reasons. Most games aren't multiplayer with anti-cheat requirements. And you're only talking about lazy, client-side anti-cheat systems.
It's impossible to verify everything between eyeball and public network. The drop-in systems available essentially check for known things, good and bad. This war on clients has a front line moving lower and lower into your computer. It used to be process and driver inspection but it's in the process of moving up to UEFI-locked ring0 (Riot's Vanguard) and it'll be a TPM-like hardware module by 2025.
There's another way: INSPECT ACTIONS. Every client knows what's going on, the server —if one exists— knows what's going on. Just replay 10 seconds leading up to a suspicious event and you very quickly discover wall-hacking, or aiming too fast and too accurately, or impossible macros. This system can be automated, cross checked by multiple clients, and you very quickly know if somebody is probably cheating.
Even if you don't want to spend time tuning your machine learning, you can just replay scenarios to other players. Hackers aren't subtle! CSGO's Overwatch is essentially crowdsourced moderation... and it works.
The reason we pretend that client-side checks are the only anti-cheat feature out there is because they're cheap. Drop-in. But they're awful for gamers' freedoms.
It's impossible to verify everything between eyeball and public network. The drop-in systems available essentially check for known things, good and bad. This war on clients has a front line moving lower and lower into your computer. It used to be process and driver inspection but it's in the process of moving up to UEFI-locked ring0 (Riot's Vanguard) and it'll be a TPM-like hardware module by 2025.
There's another way: INSPECT ACTIONS. Every client knows what's going on, the server —if one exists— knows what's going on. Just replay 10 seconds leading up to a suspicious event and you very quickly discover wall-hacking, or aiming too fast and too accurately, or impossible macros. This system can be automated, cross checked by multiple clients, and you very quickly know if somebody is probably cheating.
Even if you don't want to spend time tuning your machine learning, you can just replay scenarios to other players. Hackers aren't subtle! CSGO's Overwatch is essentially crowdsourced moderation... and it works.
The reason we pretend that client-side checks are the only anti-cheat feature out there is because they're cheap. Drop-in. But they're awful for gamers' freedoms.
>the server —if one exists— knows what's going on
Yes, but deploying even the most basic client input validation will mean we cant just ship a thin message passing shim masquerading as a server! Our cloud costs would go up by at least 20%!!1
Yes, but deploying even the most basic client input validation will mean we cant just ship a thin message passing shim masquerading as a server! Our cloud costs would go up by at least 20%!!1
You are missing the point. The games do not work.
As you said some install Kernel Level drivers (I believe this is a Ring-0 but I am not an expert in such things) as a Anti-cheat mechanism.
These do not work with Wine/Proton. e.g. Doom Eternal worked fine until the first patch and then didn't once the anti-cheat was installed (for the non-existant multiplayer community). Then they removed it only after the fanbase heavily downvoted the game on the steam store and constantly bitched to bethesda about it.
However most companies bet on most players just putting up with the bullshit to play the game and they are normally right.
I don't drop £700 on a GPU to worry about software freedoms. I buy it to play games. If I get fed up of messing about (I am the guy that runs unironically runs Arch on my desktop when not gaming and OpenBSD on my office laptop), the vast majority of players just won't even bother.
The best solution I've found is GPU passthrough (which a friend of mine has setup and I am going to try in the coming weeks) but that has it caveats and tbh Dual booting and just putting up with BS is just easier than trying to fight it.
As you said some install Kernel Level drivers (I believe this is a Ring-0 but I am not an expert in such things) as a Anti-cheat mechanism.
These do not work with Wine/Proton. e.g. Doom Eternal worked fine until the first patch and then didn't once the anti-cheat was installed (for the non-existant multiplayer community). Then they removed it only after the fanbase heavily downvoted the game on the steam store and constantly bitched to bethesda about it.
However most companies bet on most players just putting up with the bullshit to play the game and they are normally right.
I don't drop £700 on a GPU to worry about software freedoms. I buy it to play games. If I get fed up of messing about (I am the guy that runs unironically runs Arch on my desktop when not gaming and OpenBSD on my office laptop), the vast majority of players just won't even bother.
The best solution I've found is GPU passthrough (which a friend of mine has setup and I am going to try in the coming weeks) but that has it caveats and tbh Dual booting and just putting up with BS is just easier than trying to fight it.
Those games don't work. And it's important to note that occasionally those games also don't work for Windows users. New drivers, strange setups, perfectly legitimate background software, they've all upset the boat at some point, and will again in the future. Trusted Clients are fragile beasts.
It was Denuvo's Anti-Cheat and Anti-Tamper that were added retrospectively to Doom Eternal. Denuvo has a pretty awful track record even on Windows, so seeing its quick removal wasn't too surprising. If anything, the experience was positive to see a large publisher acknowledge Linux compatibility.
Games companies can keep betting on the worst anti-cheat mechanisms, I'll keep gaming on Linux thanks. I happily trade a few frames and titles to not use Windows. In my eyes, I'm better for it. If I wanted a locked down system, I'd buy a console.
It was Denuvo's Anti-Cheat and Anti-Tamper that were added retrospectively to Doom Eternal. Denuvo has a pretty awful track record even on Windows, so seeing its quick removal wasn't too surprising. If anything, the experience was positive to see a large publisher acknowledge Linux compatibility.
Games companies can keep betting on the worst anti-cheat mechanisms, I'll keep gaming on Linux thanks. I happily trade a few frames and titles to not use Windows. In my eyes, I'm better for it. If I wanted a locked down system, I'd buy a console.
Well they defintely don't work on Linux which is the point and I definetely can't play them. I personally left a negative review and removed the game until the patch was removed.
Whether the anti-cheat should be there isn't the issue. The issue is "does this stop the game from running on Linux". The answer was yes it does.
For a lot of people the only reason they buy a PC is to play games. So you might be okay saying "well I don't care about those titles" but for a lot of people those big titles with shitty DRM is literally the reason they bought the PC in the first place and saying the concern was absurd is just incorrect.
Whether the anti-cheat should be there isn't the issue. The issue is "does this stop the game from running on Linux". The answer was yes it does.
For a lot of people the only reason they buy a PC is to play games. So you might be okay saying "well I don't care about those titles" but for a lot of people those big titles with shitty DRM is literally the reason they bought the PC in the first place and saying the concern was absurd is just incorrect.
I'm not trying to give voice to every gamer, just pointing out that there's more to gaming than games that rely on this crap, and that some of us accept that.
Life is full of quasi-moral choices like this. You can choose to support hardware that supports your platform. You can choose to buy local rather than carrots flown in from South Africa; wtf Waitrose! You can donate your time to helping people hoping it makes the world slightly better.
Not playing games that go out of their way to force me to run Windows is my moral stand here. I get that it's not for you, and it's not for a lot of other Windows gamers, and it might even be stopping the Year of the Linux Desktop...
But my view is this too shall pass. Trusted Clients are bound to fail, as they have again and again and again. They're running out of options. Engines with action integrity checks are the future. And e-sports will move to the cloud because that just makes sense for everybody involved.
Life is full of quasi-moral choices like this. You can choose to support hardware that supports your platform. You can choose to buy local rather than carrots flown in from South Africa; wtf Waitrose! You can donate your time to helping people hoping it makes the world slightly better.
Not playing games that go out of their way to force me to run Windows is my moral stand here. I get that it's not for you, and it's not for a lot of other Windows gamers, and it might even be stopping the Year of the Linux Desktop...
But my view is this too shall pass. Trusted Clients are bound to fail, as they have again and again and again. They're running out of options. Engines with action integrity checks are the future. And e-sports will move to the cloud because that just makes sense for everybody involved.
> I'm not trying to give voice to every gamer, just pointing out that there's more to gaming than games that rely on this crap, and that some of us accept that.
That wasn't what I was taking umbrage with. You dismissing the concerns as absurd was what I was taking umbrage with.
> Life is full of quasi-moral choices like this.
Yes understand this.
> You can choose to support hardware that supports your platform. You can choose to buy local rather than carrots flown in from South Africa; wtf Waitrose! You can donate your time to helping people hoping it makes the world slightly better.
I don't wish to be rude but you are being so overly dramatic.
> Not playing games that go out of their way to force me to run Windows is my moral stand here. I get that it's not for you, and it's not for a lot of other Windows gamers, and it might even be stopping the Year of the Linux Desktop...
The dramatic language aside. Yes that is your choice. However a lot of games at the moment require this, so proton as good as it is won't run these games and that is a deal breaker for many people. Whether or not you continue with your moral crusade will make no difference to the current reality.
As for the year of the Linux desktop. It is never going to happen. I've been using alternative Operating systems such as Lnux for about 17 years. I've tried 21 XFCE, Gnome, KDE, Cinnamon, mucked about with windows managers and there is always some really irritating bugs that never get resolved and have been there for years on end. That combined with almost every Linux distribution kinda breaking itself as time goes on and requiring you to drop to the terminal to fix it (I have used many distros over the years).
> But my view is this too shall pass. Trusted Clients are bound to fail, as they have again and again and again. They're running out of options. Engines with action integrity checks are the future. And e-sports will move to the cloud because that just makes sense for everybody involved.
I doubt it. It is a good enough solution. These cloud based services have bunch of input latency which is just unacceptable. Many of the large games before covid happened over lan in stadiums, once covid is over we will go back to this.
I suspect with esports I think cheating will be discovered by observing replays at the higher levels. (this already happens in the speed running community).
That wasn't what I was taking umbrage with. You dismissing the concerns as absurd was what I was taking umbrage with.
> Life is full of quasi-moral choices like this.
Yes understand this.
> You can choose to support hardware that supports your platform. You can choose to buy local rather than carrots flown in from South Africa; wtf Waitrose! You can donate your time to helping people hoping it makes the world slightly better.
I don't wish to be rude but you are being so overly dramatic.
> Not playing games that go out of their way to force me to run Windows is my moral stand here. I get that it's not for you, and it's not for a lot of other Windows gamers, and it might even be stopping the Year of the Linux Desktop...
The dramatic language aside. Yes that is your choice. However a lot of games at the moment require this, so proton as good as it is won't run these games and that is a deal breaker for many people. Whether or not you continue with your moral crusade will make no difference to the current reality.
As for the year of the Linux desktop. It is never going to happen. I've been using alternative Operating systems such as Lnux for about 17 years. I've tried 21 XFCE, Gnome, KDE, Cinnamon, mucked about with windows managers and there is always some really irritating bugs that never get resolved and have been there for years on end. That combined with almost every Linux distribution kinda breaking itself as time goes on and requiring you to drop to the terminal to fix it (I have used many distros over the years).
> But my view is this too shall pass. Trusted Clients are bound to fail, as they have again and again and again. They're running out of options. Engines with action integrity checks are the future. And e-sports will move to the cloud because that just makes sense for everybody involved.
I doubt it. It is a good enough solution. These cloud based services have bunch of input latency which is just unacceptable. Many of the large games before covid happened over lan in stadiums, once covid is over we will go back to this.
I suspect with esports I think cheating will be discovered by observing replays at the higher levels. (this already happens in the speed running community).
My dismissal of the original statement is well explained.
While some games with some anti-cheats won't work on Linux, the vast majority work well. There are options for viable future anti-cheats on Linux, between recreating what's been done for Windows, simple reputation systems, community moderation and actual event audits. The reason they'll be contemplated is the continued failure of trusted clients. And the significance of the 13 [of top 100] games that currently don't work is entirely down to player preferences.
Dramatics: you seem to be a person that understands the problem, understands individuality, but refuses to paint as more than a binary outcome. There are already a million gamers playing games on Linux, there's clearly room in the middle, and positive road to the future.
E-sports: the elite will continue to happen at real venues, but I think there's going to be significant growth in the every-day teams. Think five-a-side pub teams. They're not going to rent a £15k/d venue like Multiplay can, they're going to play online and need a way to ensure that all players are playing with the same tools. A cloud-rendered system does that and it'll only become more feasible in time. Yes, there's higher latency, but it's a known latency.
While some games with some anti-cheats won't work on Linux, the vast majority work well. There are options for viable future anti-cheats on Linux, between recreating what's been done for Windows, simple reputation systems, community moderation and actual event audits. The reason they'll be contemplated is the continued failure of trusted clients. And the significance of the 13 [of top 100] games that currently don't work is entirely down to player preferences.
Dramatics: you seem to be a person that understands the problem, understands individuality, but refuses to paint as more than a binary outcome. There are already a million gamers playing games on Linux, there's clearly room in the middle, and positive road to the future.
E-sports: the elite will continue to happen at real venues, but I think there's going to be significant growth in the every-day teams. Think five-a-side pub teams. They're not going to rent a £15k/d venue like Multiplay can, they're going to play online and need a way to ensure that all players are playing with the same tools. A cloud-rendered system does that and it'll only become more feasible in time. Yes, there's higher latency, but it's a known latency.
This is a very good comment. See this thread how Riot basically dictates what people are allowed to run or install on their system just to run a stupid game. https://www.reddit.com/r/VALORANT/comments/g3yqxd/psa_riot_v...
Leave moderation to players, it's way more effective than any sort of client side cheat detection.
Leave moderation to players, it's way more effective than any sort of client side cheat detection.
People are insane to begin with to install some rootkit on their system just to play a game.
It's trivial (if you know what you are doing) to load kernel drivers from userspace by abusing windows bugs.
If you trust a program to run in userspace, then it already has all the keys to the kingdom.
Welcome to windows security.
Welcome to windows security.
Strange, I can do the same in Linux.
Welcome to GNU/Linux security.
Welcome to GNU/Linux security.
A lot of the times you won't know unless you go digging through review comments or people have made a fuss over it.
To some people, the priority is the game and they couldn't care less about the borderline malware required to do so.
Most people installing these games don't even know what a rootkit is.
passthrough and the required VM also has issues with many anticheat, right?
Many anti-cheat rootkits detect VM and blocks you.
Windows is probably moving in this direction too, so games will have to figure it out regardless. New installs of Windows 10 run in a VM; drivers no longer have access to the entire machine.
https://docs.microsoft.com/en-us/windows-hardware/design/dev...
https://docs.microsoft.com/en-us/windows-hardware/design/dev...
https://docs.microsoft.com/en-us/windows-hardware/design/dev...
https://docs.microsoft.com/en-us/windows-hardware/design/dev...
The irony of desktop computers in 2020 catching up with OS/360.
I'm likewise fascinated about how terrible Steam's CLIENT works on Linux. Like, no hidpi support, (it's just blurry), notifications don't work, and lots of other stuff is broken. Sometimes closing a popup closes the main window, but only for _some_ kinds of popups. It also only works via X11 / XWayland.
Fortunately, they keep getting all the really hard stuff done.