Valve Is Working on Another Extension to Help in Direct3D-over-Vulkan
phoronix.com
phoronix.com
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.
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 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).
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.
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.
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.
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.)
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.
If the games start to run on Linux, what's still keeping people on Windows?
Agreed, Cortana is a big reason to avoid Windows.
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.'
Most "actual serious work" involves receiving and modifying other peoples' drafts. As such, if anyone uses an advanced feature, everyone uses the advanced feature.
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.
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.
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
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.
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.
Having said that, I haven't experienced any of the issues mentioned.
They can either use an existing display server, or write their own. The latter would be absurdly more expensive.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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).
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.
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.
XWayland does not support scaling, so I don't see how it can "work fine".
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.
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).
I use 200% scaling on the desktop, and this exact checkbox makes Steam use 2x as well.
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:
ProtonDB and WineHQ are good resources for users as well.
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'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.
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?
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).
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 ).
And Collabora: https://www.gamingonlinux.com/2020/10/collabora-expect-their...
*I work at Google but not on anything related to Stadia.
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.
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.
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.
Or for wine
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.
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?
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
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 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.
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.
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
If the market is big enough, cross platform development is viable from the start.
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.
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 better ports use the native APIs of course, but are few and far between.
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.
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.
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.
Out of curiousoity, was this new system also using Nvidia graphics? Or were they otherwise fairly new cards both times?
"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
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 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.
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).
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...
As you noted: if the solution were so trivial it would have been done and shipped already.
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.
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?
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.
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 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.
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.
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.
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'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.
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...
[1] https://source.winehq.org/git/wine.git/?a=search&h=HEAD&st=a...
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.
Okay: Any possibility to support their open source work? (except of using steam)
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...
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).
Valve own marketing material doesn't count.
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.
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.
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.
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.
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.
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 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.
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.
- https://get.webgl.org/webgl2/
- https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_...
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
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!
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.
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.
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!
Does anyone know how to "share" the game resources so that the Linux version only download the executable/runner?
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
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
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.
https://docs.microsoft.com/en-us/sysinternals/downloads/stre...
2) I seriously doubt any game uses alternate data streams for anything.
I gave up and just created an ext4 partition and things got a lot more stable.
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
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.
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.
You could try Wine, I haven't tried that.
Age of Empires 2 (2013) - Platinum
Age of Empires 3 - Gold
Age of Empires 2 - Gold
Age of Empires - Gold
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.
Steam -> Settings -> Steam Play and tick "Enable Steam Play for all titles"
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.
Or are they a generous corporate machine doing it out the goodness of their heart?
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.
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.
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.
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.
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.
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.
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).
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.
Leave moderation to players, it's way more effective than any sort of client side cheat detection.
Welcome to windows security.
Welcome to GNU/Linux security.
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
https://docs.microsoft.com/en-us/windows-hardware/design/dev...
https://docs.microsoft.com/en-us/windows-hardware/design/dev...