In my purely anecdotal experience over the last few years, performance ranking is as follows:
1. Steam on Linux via Proton + Wayland (Niri)
2. Steam on Linux via Proton + X11 (Xfce)
3. Steam on Windows
4. Games on Linux launched via other means (it's possible I was missing out on certain flags/optimizations, but this is just about the average experience)
The biggest thing I noticed when switching to Linux was an improvement in framerate consistency, i.e. I'd have fewer situations where the framerate would drop momentarily. Games felt more solid and predictable.
The biggest thing I noticed when switching from X11/Xfce to Wayland/Niri was just an overall increase in framerate. I'd failed this jump many times over the years, so it was notable when I jumped and stayed there earlier this year.
It does feel like games take longer to launch on average, but this makes sense given the fact that it's launching via Proton/Wine.
Interestingly enough, I've had games that had both a native Linux port and Windows version, and the Windows version through Proton ran better than the native Linux version. This ended up being true for Civ5, Civ6 and Cities Skylines (1).
With those admittedly limited examples though, I don't experience the same ranking in performance, but I attribute that to my non-gaming hardware vs. any problem with Linux or Proton/Wine. I play on a laptop with an Nvidia 3050 laptop GPU, and I get much better performance in Windows still. In Cities Skylines, for example, I'll get ~20 fps on Linux via Proton (but I do experience what you said, it's consistent no major spikes or drops) while on Windows I get between 45-60fps up until about 15k population or so.
Other games, despite working, remain unplayable to me due to performance. I can play Diablo 4 on windows no problem on medium settings, but even on low it's just too unresponsive on Linux.
Anyway, just my anecdotal experience. Those with dedicated gaming rigs will be more than fine with Linux, but those of us on underpowered hardware still seem better off with Windows, unfortunately.
Linux port if there is one is usually done by a third party porting studio, which is not necessarily at the same quality as the original codebase. Also the devs just don't have the manpower/bandwidth to spare for Linux users given how small this community is.
It's better value for money for both the gamers and the devs if the devs just choose to engage with valve and get their game running perfectly under proton.
> Anyway, just my anecdotal experience. Those with dedicated gaming rigs will be more than fine with Linux, but those of us on underpowered hardware still seem better off with Windows, unfortunately.
On the other hand, Linux (or more accurately, the Linux desktop ecosystem) doesn't support a lot of high-end PC gaming features well: HDR, Nvidia GPUs, VR, etc.
I wonder of this might be due to your Linux nvidia driver (nouveau?) pinning the card on baseclock by default while the Windows one will allow it to scale up? Something I heard somewhere that seems applicable here.
In that case it might not be anything the game devs or Steam can do anything about but something you'd have to fiddle with on your system.
> Those with dedicated gaming rigs will be more than fine with Linux, but those of us on underpowered hardware still seem better off with Windows, unfortunately.
That’s interesting and good to know. I’m running an 10th gen i9 with an RTX 3090, so I have plenty of headroom performance wise. I’ve been wondering about Linux gaming on lower end hardware for my younger brother’s sake, and hadn’t assumed it would be worse.
One thing to note: I’ve had all kinds of issues with power management impacting performance. If I let the computer sleep/standby, I’ll get 50% slower framerate until I reboot.
Given the fact that you’re on a laptop, I wonder if power management has contributed to the slowness.
I have a laptop with the same GPU, and Diablo 4 runs really well out of Lutris. Graphics version 570, and the CPU is an AMD with a Radeon 680M integrated. I often play games with FSR on, which probably keeps performance higher?
Side note, Niri is a fantastic WM. When I saw the Phoronix article on HN talking about the addition of overview mode and more, I finally took the plunge and spent an afternoon converting over from Sway.¹ Anecdotally, I've seen less hangups on Niri around fullscreen games and floating windows, perhaps thanks to X11 running in xwayland-satellite.
1: the hardest part was finding a bar that supported i3status-rs; not a fan of GTK bars that eat up CPU. I settled on i3bar-river.
I wish more Wayland compositors took this option, seems like a cleaner method of keeping X compatibility and not allowing Xwayland to bring down the entire compositor.
I've been so happy with Niri after many many years bouncing around other WMs. It addresses the main issues I've had with other tiling window managers and has been such a joy to use.
The scrollable aspect just feels so natural and intuitive to me.
Steam won't launch for me in xwayland-satellite here... I just assumed steam+wayland = broken. I have a kind of weird setup using sway with xwayland disabled and running xwayland-satellite though.
Been a Linux gamer for years now and I think you are correct on your frame rate observations in general.
If you use ZFS (single nvme) then you can beat windows load times by a fairly large margin. My husband and I have identical hardware for our gaming computers (he uses Windows and I run Linux), it's not uncommon for my computer to load games 10 seconds faster than his.
> The biggest thing I noticed when switching from X11/Xfce to Wayland/Niri was just an overall increase in framerate.
Was it with any specific game? I just tried the GOG version of The Witcher 3 "Complete Edition" (which is the remastered one) with the Direct3D 12 renderer under both Xorg/Window Maker and Wayland/KDE using umu-run (essentially proton without Steam) and it had identical performance in both cases (i also tried to use Niri but it would launch in 60Hz mode and for some reason wouldn't allow the game to run at a higher framerate with vsync disabled regardless of any option i chose) in either low or high settings (which is basically what i expected since the window system shouldn't be a bottleneck unless something is either broken or you are running at something like 20000fps :-P).
Some of the games I play often that saw improvements: The Finals, Overwatch, Rocket League, Helldivers.
> (i also tried to use Niri but it would launch in 60Hz mode and for some reason wouldn't allow the game to run at a higher framerate with vsync disabled regardless of any option i chose)
I had some issues early on related to refresh rate, and it turned out I didn't have an output defined for the correct display. The steps I took:
1. Run `niri msg outputs` to identify the Display ID and available modes. In my case: "DP-3" and "2560x1440@143.964"
2. Set up an output in niri's confid.kdl as follows:
Is there a way of making wayland actually usable with Nvidia GPUs? I never manage to make it work, and it makes the whole system feel slow and sluggish compared to X11
> It does feel like games take longer to launch on average, but this makes sense given the fact that it's launching via Proton/Wine.
Also anecdotal, but I feel like Steam games on Linux compile shaders on the CPU, and maybe not super optimized, compared to Windows where they either ship with precompiled shaders, or it might use the GPU?
Still, the very same games runs better on Wayland+Linux too for me, than on Windows, way less stutters in particular as you mention.
But I'm not sure if it's because of OS differences, or that it's so much easier to end up bloating a Windows install. I can't say I treat them the same, as one is mostly a work environment and the other one purely entertainment and creative usage.
The last missing piece for full Linux gaming is anticheat. Last I looked into it, the major vendors don’t want to support it due to lack of kernel security and the ones that do, game devs refuse to allow it (destiny for example)
One we can play AAA games I am literally ditching windows forever. Steamos is the best thing that has happened to gaming
Anti-cheat today is a stop-gap measure at best. For various reasons such as improved OS security and security concerns with this software, ring zero anti-cheat won't be around forever. Besides, it's a cat and mouse game where the vendor is the mouse.
We already have the technology now to do it better. A combination of only sending what info a client should have, and server-side checks. As soon as something like UT ships with that built in we can hopefully forget about this horrible hack we currently have to check for cheats.
> Besides, it's a cat and mouse game where the vendor is the mouse.
The goal of anti-cheat isn't to stop the world's most advanced cheaters. Those are already unstoppable because they now use Direct Memory Access over the PCI-E bus, so the cheats don't even run on the same computer anymore. However since those cheaters are few and far in-between they can be handled through player reports.
The goal is to stop the mediocre cheater who simply downloaded a known cheat from a cheating forum. If you don't stop those you'll get such a large wave of cheaters that you can't keep up with banning them quickly enough.
As long as games are running on user hardware/OS, you'll always deal with cheating. Server-side checks and computation can only go so far.
For example: in competitive shooters (where cheaters are most prevalent) you can't have things appearing out of thin air. The client needs to know about things ahead of time to play sounds and to give other environmental hints.
> Anti-cheat today is a stop-gap measure at best. For various reasons such as improved OS security and security concerns with this software, ring zero anti-cheat won't be around forever.
I think that traditional kernel-level anticheat is going away. But the reason is more that when CrowdStrike caused mass outage, Microsoft stated that they want to provide standard interfaces for security sensors, and forbid kernel-level access otherwise (and anticheat can be considered a kind of security sensor too).
If these interfaces become standardized then Valve/Linux could in principle implement them too.
The goal isn’t to stop 100% of cheats but the majority of them and that’s fine. Either way, it’s the only thing stopping me from playing the rest of my games on steamos.
Multiplayer games without dedicated servers is dead end anyways. I dont need a "anti-cheat" daemon hooking into kernel scanning files and other memory while playing a game. Communities in dedicated servers are much more efficient at moderating the player base than centralized match making ever will be.
This is where I'm at with gaming. Even outside of cheating, it's not fun to me to be dumped in a game with screaming children/manchildren. If I'm playing a game I want it to be with my actual friends. And then I don't have to worry about them running cheats because I trust them.
Once you get to match making, global ranks, etc it's just getting too sweaty and ruined by cheating/low trust/etc.
Communities with dedicated servers include anti-cheat though. Most people aren't interested in spending time moderating a player base: they'd rather just play the game. So server admins use anti-cheat.
You can see this in existing games with current games with community servers. GTA V's modded FiveM and CS2 Face-IT include more anti-cheats, not less.
Yeah, but it's very time consuming/impossible to find similarly skilled players for a fun lobby. The only competitive game I care to play on Linux is Rocket League, which is nearly impossible to cheat at, so it doesn't currently have anti-cheat, but I wouldn't be surprised if Epic decides to put their beloved EAC in it at some point anyway, maybe even just because they hate Linux so much.
They really aren’t. I used to think that but I actually enjoy skill based matchmaking. It makes game availability better and faster and I don’t have to deal with 1 outlier absolutely stomping or overzealous admins or whatever. I like both approaches though for something like battlefield I think dedicated servers are better but for things like cod, siege, etc we need sbmm
It's also an anticompetitive red herring, at least for Epic.
They say they don't support Linux because it's too complicated to be worth the ROI. Really, it's that they don't want to boost a platform where Steam is far and away the default store.
This is problem for me and my brother right now. He's up at a remote job site and we want to play Siege or Apex together¹, but both require anti-cheat and don't support Linux. And I'm loathe to devote space on my SSD to Windows.
¹: Rainbow Six: Siege and Apex Legends, respectively.
The two most popular ACs by far are Easy anti cheat and Battle eye which have natively supported Linux for years, but it is entirely up to the game devs to enable it.
About 40% of all games with AC are working areweanticheatyet.com
There are rumours of next xbox generation supporting steam platform and 386 architecture. I know it's a bit off topic, but it could be an elegant solution to the cheating problem, gradually move to standardised consoles. This could solve the dma problem too
AFAIK most anti cheats such as BattlEye actually work under Proton, but the Game Developers have to write to the Anticheat vendor that they want to opt-in into allowing Proton.
Don't forget the ancillary applications that gamers want. If you follow Discord's website, you're gonna end up installing a DEB file manually. Then, every couple weeks, Discord won't launch until you go download another DEB file and install that. Oh, and good luck getting Discord screen sharing working on Wayland. I tried for hours, gave up, and switched to X11. So, just in Discord, we've already run into two hideous workflows that no Windows native is going to take in stride.
And certain types of games have a _ton_ of ancillary applications. For flight simulation, I rely on 2-3 additional contollers, some of which I am fairly certain either won't have driver support, or at the very least will have some major issues with the GUI and configuration.
Then, there are things like head tracking which are either another dedicated peripheral which may or may not get drivers, or a set of apps which feed from a webcam and output the signal to a standard driver that games know to check for.
Finally, most 3rd party add-ons have custom installers, and I'm guessing most of them won't have a working Linux version. So, while I'm sure it's possible to run, say, a vanilla X-Plane on a non-Windows installation with no peripherals/apps/add-ons, I just see a mountain of work to get a normal, heavily custom installation working.
Discord is shipped in a number of package managers (I don’t know the status for mainline apt repos).
I know that this isn’t an easy solution/doesn’t go against your argument, because it isn’t download-and-run simple, but discord’s version can be modified with no consequences in a build_info.json file. I used to do it manually, back when they updated it every once-in-a-while, but due to their current tendency to push updates every few days or so, I’ve made a few-line bash script to fetch the latest version (thank you httptap) and patch the file for me. For screen sharing, I use whatever current discord client on GitHub supports it for Wayland, which usually has the added benefit of not limiting quality and framerate options.
But yes, you do have a point, it’s not just ‘as simple’ as it is under Windows - when Windows works properly.
It's funny because one of the OG draws to Steam back in the day was because Counter-Strike (et al) had the superior Valve Anti-Cheat (VAC) in Steam copies than the myriad of raw CD installs of HL1 plus the mods to run Counter-Strike.
This missing piece is sort of a fun "whatever happened to VAC and why hasn't it kept up with the times?"
It seems like Linux would be a good excuse to reinvest in VAC and make it a bigger competitor to the current favorites like Easy Anti-Cheat (EAC).
interestingly, I have no issues with the anti-cheat within Marvel Rivals; however, games that embedded an anti-cheat prior to the steam deck popularity don’t work as you described (PUBG, apex legends).
Given that Windows games run faster via Proton on SteamOS, developers should prioritize targeting SteamOS APIs—not Windows. This ensures compatibility with Windows while maximizing performance. Game engines like Unity and Unreal must adopt SteamOS as the primary target, with CI systems rigorously testing both platforms. SteamOS, not Windows, should be the baseline for optimization.
Does Valve run a SteamOS CI/CD farm? I could see a Rust based template and library for calling into this set of APIs that you could upload your well structured project and it would build and test for all platforms. Rust would just be the skeleton, your game logic could be in anything Rust could link to.
I'm not sure that makes sense since the Windows API is the source of truth for how something works. If you make a game that works on Windows but not in Proton, Valve will push a fix that makes Proton work the same as Windows. But if you make your game work with Proton, but not Windows, you are relying on some quirk of Proton which isn't guaranteed to work in to the future and as soon as something else needs it to work the same as Windows, your game will break.
Test your game to make sure it works on the Steam Deck and avoid features that don't work on Proton, but you still have to primarily target Windows.
You would need to test on both of course. I am arguing that one should target the fast happy-path on Proton as Proton is a subset of the Windows APIs that runs faster than Windows.
Valve actually ships "stable ABI" Linux runtimes that Linux games and Proton are built against, so that they don't have to rely on distribution packages, similarly to Flatpak. They renew them every few years but they stay stable so that games built against a specific runtime keep working.
Ignoring that, you know, 99% of users are running Windows and not SteamOS. Test on what your users run. Proton is just an implementation of Win32, you're still just targeting Windows.
Back in the Windows XP days, I discovered that running Windows in a VMWare VM, hosted on Linux, was faster than running the same version of Windows bare on the same machine.
Recently switched as well (Arch not steamOS, which is arch based) and it's been pretty solid.
Not out of box - games require mild tweaking but nothing wildly challenging. Add parameter to launch command line etc. The proton database & comments on there usually explain what tweaks the game needs
Some of these games are practically neck and neck for performance. I'm wondering if it's a similar situation to early Proton comparisons, where framerates were higher in Proton but when comparing still for still you could tell it just wasn't actually doing certain effects. Are there features that are being attempted in the Windows version that are just not functional and thus effectively disabled on the Proton one?
But even then, assuming that is true, if they're pretty much the same would people care about maybe some fog looks a little different but you get an extra 15-20fps in a game? I think a lot of people would still prefer the boost in frames.
Might be unfair to call Proton a "translation layer" because the Win32 API is not defined in terms of system calls but rather a set of functions exported from a DLL.
Proton supplies a DLL that implements the Win32 API using Linux syscalls. Windows supplies a DLL that implements that Win32 API using Windows syscalls that you're not really supposed to use directly.
Clearly they don't want to come out and say that Wine is an "implementation of windows apis", because that would invite legal issues. But clearly this is what Wine really is for a large part. Some stuff are just shallow shims to Linux apis, while other stuff they need to make more of their own implementation of.
I really have to respect Wine's persistence (with Proton's help).
For so long it was one of those "and now you have two problems" technologies and now it looks like it's the slow blade that could actually kill Windows.
Wine is translating Windows ABIs (not APIs) into underlying Linux OS and userland. Translation simply means that normally Windows ABIs are meant to be used on Windows, they aren't native on Linux.
Also, most games are still 32-bit EXEs, so on most PCs today they are running not just in the Win32 subsystem, but the WOW64 subsystem (Windows-on-Windows 64) the compatibility layer of running 32-bit Windows applications on top of 64-bit Windows and its Win32 subsystem (it's still called Win32 on 64-bit, an unfortunate naming bug from massive compatibility break differences between Win16 and Win32 that didn't exist in the 64-bit transition, 64-bit didn't get a new API subsystem, it just upgraded the existing one, mostly).
Readit News
1. Steam on Linux via Proton + Wayland (Niri)
2. Steam on Linux via Proton + X11 (Xfce)
3. Steam on Windows
4. Games on Linux launched via other means (it's possible I was missing out on certain flags/optimizations, but this is just about the average experience)
The biggest thing I noticed when switching to Linux was an improvement in framerate consistency, i.e. I'd have fewer situations where the framerate would drop momentarily. Games felt more solid and predictable.
The biggest thing I noticed when switching from X11/Xfce to Wayland/Niri was just an overall increase in framerate. I'd failed this jump many times over the years, so it was notable when I jumped and stayed there earlier this year.
It does feel like games take longer to launch on average, but this makes sense given the fact that it's launching via Proton/Wine.
With those admittedly limited examples though, I don't experience the same ranking in performance, but I attribute that to my non-gaming hardware vs. any problem with Linux or Proton/Wine. I play on a laptop with an Nvidia 3050 laptop GPU, and I get much better performance in Windows still. In Cities Skylines, for example, I'll get ~20 fps on Linux via Proton (but I do experience what you said, it's consistent no major spikes or drops) while on Windows I get between 45-60fps up until about 15k population or so.
Other games, despite working, remain unplayable to me due to performance. I can play Diablo 4 on windows no problem on medium settings, but even on low it's just too unresponsive on Linux.
Anyway, just my anecdotal experience. Those with dedicated gaming rigs will be more than fine with Linux, but those of us on underpowered hardware still seem better off with Windows, unfortunately.
It's better value for money for both the gamers and the devs if the devs just choose to engage with valve and get their game running perfectly under proton.
On the other hand, Linux (or more accurately, the Linux desktop ecosystem) doesn't support a lot of high-end PC gaming features well: HDR, Nvidia GPUs, VR, etc.
In that case it might not be anything the game devs or Steam can do anything about but something you'd have to fiddle with on your system.
That’s interesting and good to know. I’m running an 10th gen i9 with an RTX 3090, so I have plenty of headroom performance wise. I’ve been wondering about Linux gaming on lower end hardware for my younger brother’s sake, and hadn’t assumed it would be worse.
One thing to note: I’ve had all kinds of issues with power management impacting performance. If I let the computer sleep/standby, I’ll get 50% slower framerate until I reboot.
Given the fact that you’re on a laptop, I wonder if power management has contributed to the slowness.
1: the hardest part was finding a bar that supported i3status-rs; not a fan of GTK bars that eat up CPU. I settled on i3bar-river.
I wish more Wayland compositors took this option, seems like a cleaner method of keeping X compatibility and not allowing Xwayland to bring down the entire compositor.
The scrollable aspect just feels so natural and intuitive to me.
If you use ZFS (single nvme) then you can beat windows load times by a fairly large margin. My husband and I have identical hardware for our gaming computers (he uses Windows and I run Linux), it's not uncommon for my computer to load games 10 seconds faster than his.
Was it with any specific game? I just tried the GOG version of The Witcher 3 "Complete Edition" (which is the remastered one) with the Direct3D 12 renderer under both Xorg/Window Maker and Wayland/KDE using umu-run (essentially proton without Steam) and it had identical performance in both cases (i also tried to use Niri but it would launch in 60Hz mode and for some reason wouldn't allow the game to run at a higher framerate with vsync disabled regardless of any option i chose) in either low or high settings (which is basically what i expected since the window system shouldn't be a bottleneck unless something is either broken or you are running at something like 20000fps :-P).
> (i also tried to use Niri but it would launch in 60Hz mode and for some reason wouldn't allow the game to run at a higher framerate with vsync disabled regardless of any option i chose)
I had some issues early on related to refresh rate, and it turned out I didn't have an output defined for the correct display. The steps I took:
1. Run `niri msg outputs` to identify the Display ID and available modes. In my case: "DP-3" and "2560x1440@143.964"
2. Set up an output in niri's confid.kdl as follows:
Also anecdotal, but I feel like Steam games on Linux compile shaders on the CPU, and maybe not super optimized, compared to Windows where they either ship with precompiled shaders, or it might use the GPU?
Still, the very same games runs better on Wayland+Linux too for me, than on Windows, way less stutters in particular as you mention.
But I'm not sure if it's because of OS differences, or that it's so much easier to end up bloating a Windows install. I can't say I treat them the same, as one is mostly a work environment and the other one purely entertainment and creative usage.
One we can play AAA games I am literally ditching windows forever. Steamos is the best thing that has happened to gaming
We already have the technology now to do it better. A combination of only sending what info a client should have, and server-side checks. As soon as something like UT ships with that built in we can hopefully forget about this horrible hack we currently have to check for cheats.
The goal of anti-cheat isn't to stop the world's most advanced cheaters. Those are already unstoppable because they now use Direct Memory Access over the PCI-E bus, so the cheats don't even run on the same computer anymore. However since those cheaters are few and far in-between they can be handled through player reports.
The goal is to stop the mediocre cheater who simply downloaded a known cheat from a cheating forum. If you don't stop those you'll get such a large wave of cheaters that you can't keep up with banning them quickly enough.
For example: in competitive shooters (where cheaters are most prevalent) you can't have things appearing out of thin air. The client needs to know about things ahead of time to play sounds and to give other environmental hints.
I think that traditional kernel-level anticheat is going away. But the reason is more that when CrowdStrike caused mass outage, Microsoft stated that they want to provide standard interfaces for security sensors, and forbid kernel-level access otherwise (and anticheat can be considered a kind of security sensor too).
If these interfaces become standardized then Valve/Linux could in principle implement them too.
Any anti-malware software ends up ultimately being a cat and mouse game, but that doesn't mean we stop updating our signature updates.
Once you get to match making, global ranks, etc it's just getting too sweaty and ruined by cheating/low trust/etc.
You can see this in existing games with current games with community servers. GTA V's modded FiveM and CS2 Face-IT include more anti-cheats, not less.
I want good balanced matches with players of my similar skill level via matchmaking.
They say they don't support Linux because it's too complicated to be worth the ROI. Really, it's that they don't want to boost a platform where Steam is far and away the default store.
ETA: EAC still supports Linux gaming today, but the rumors remain that Epic could remove that at their whim.
Just avoid it.
¹: Rainbow Six: Siege and Apex Legends, respectively.
The two most popular ACs by far are Easy anti cheat and Battle eye which have natively supported Linux for years, but it is entirely up to the game devs to enable it.
About 40% of all games with AC are working areweanticheatyet.com
Then, there are things like head tracking which are either another dedicated peripheral which may or may not get drivers, or a set of apps which feed from a webcam and output the signal to a standard driver that games know to check for.
Finally, most 3rd party add-ons have custom installers, and I'm guessing most of them won't have a working Linux version. So, while I'm sure it's possible to run, say, a vanilla X-Plane on a non-Windows installation with no peripherals/apps/add-ons, I just see a mountain of work to get a normal, heavily custom installation working.
I know that this isn’t an easy solution/doesn’t go against your argument, because it isn’t download-and-run simple, but discord’s version can be modified with no consequences in a build_info.json file. I used to do it manually, back when they updated it every once-in-a-while, but due to their current tendency to push updates every few days or so, I’ve made a few-line bash script to fetch the latest version (thank you httptap) and patch the file for me. For screen sharing, I use whatever current discord client on GitHub supports it for Wayland, which usually has the added benefit of not limiting quality and framerate options.
But yes, you do have a point, it’s not just ‘as simple’ as it is under Windows - when Windows works properly.
It Just Works.
This missing piece is sort of a fun "whatever happened to VAC and why hasn't it kept up with the times?"
It seems like Linux would be a good excuse to reinvest in VAC and make it a bigger competitor to the current favorites like Easy Anti-Cheat (EAC).
Not a big issue if you're just using kb/mouse/controller but you can get into the weeds with VR, flight sticks, wheels, etc.
Does Valve run a SteamOS CI/CD farm? I could see a Rust based template and library for calling into this set of APIs that you could upload your well structured project and it would build and test for all platforms. Rust would just be the skeleton, your game logic could be in anything Rust could link to.
Test your game to make sure it works on the Steam Deck and avoid features that don't work on Proton, but you still have to primarily target Windows.
https://github.com/ValveSoftware/steam-runtime
I never came up with a good explanation for that.
Disk cache, to be precise.
Not out of box - games require mild tweaking but nothing wildly challenging. Add parameter to launch command line etc. The proton database & comments on there usually explain what tweaks the game needs
Don't think I'll switch back
But even then, assuming that is true, if they're pretty much the same would people care about maybe some fog looks a little different but you get an extra 15-20fps in a game? I think a lot of people would still prefer the boost in frames.
Proton supplies a DLL that implements the Win32 API using Linux syscalls. Windows supplies a DLL that implements that Win32 API using Windows syscalls that you're not really supposed to use directly.
so 'translation layer' is not that unfair.
For so long it was one of those "and now you have two problems" technologies and now it looks like it's the slow blade that could actually kill Windows.
https://blog.zorinaq.com/i-contribute-to-the-windows-kernel-...
https://news.ycombinator.com/item?id=38936868