Amazing, you can buy a triple A title and have it just work out of the box. I'm so happy with Valve's support for linux. And of course the thousands of hours of work that have gone into Wine.
It's becoming a more reliable experience to play old windows games using wine than trying to run them on windows 10.
Also DXVK [1], an implementation of DirectX over Vulkan that allows (most) games to run on Linux with native or even better performance. Some people are using DXVK even on Windows to circumvent bugs or simply because it's faster for some DX9 games.
A friend of mine recently got a workstation with a threadripper processor, and apparently some games have so much trouble with the core count (lookin' at you, Far Cry) that you have to reboot into "game mode" with a substantial number of cores disabled.
But some other enterprising threadripper user worked around that by stuffing the game in a Linux VM to avoid the rebooting.
Crazy to think that a Windows game would perform better in a Linux VM under Windows than running on Windows natively, even if the reason is that it's effectively presenting the game with worse hardware that it understands how to use more effectively.
I believe that they got rid of the grace period in Windows 10. Now you can run Windows without a license key indefinitely, albeit with certain personalization features (e.g. color scheme, wallpaper) locked.
Only for personal usage, businesses may still need to show licenses and with telemetry, it’s easier for Microsoft to find such usages. That said, with the switch to Linux servers, Windows is probably a declining business for Microsoft while Azure and Office are growing, hence “Microsoft 365” subscriptions.
I believe for non-production usage, Microsoft is okay with unlicensed or trial Virtual Machines and such. The idea being that if developers are testing their software in Windows, that’s better than the alternative (not testing their software in Windows).
Similarly, if willing to beta test versions of software, you can get Visual Studio for “Insiders” and test the Enterprise edition for free with a non-production license for as long as newer beta versions are made available. (Note: IANAL, this ain’t legal advice, read the terms and conditions on any Microsoft VMs or software installations)
There is a permanent Windows Activation message (white text on transparent background) in the lower right part of the screen which my brain already blocked so it's not distracting at all. I only notice it after taking screenshots.
I'm surprised that you can't just lock the game's threads to a smaller number of cores, but I can imagine the DRM some games ship with preventing you from doing it. Booting up a VM with its core count limited is a clever workaround... I'm guessing a Windows VM would have reduced GPU performance because of the way pass-through works.
Game Mode is a new feature in AMD Ryzen™ Master that reconfigures the platform in two key ways:
• It temporarily disables half of the CPU cores, which turns the AMD Ryzen Threadripper 1950X into an 8C16T device (like the AMD Ryzen™ 1800X) and the 1920X into a 6C12T device (like the AMD Ryzen™ 1600X). For the truly technical, this is a 4+4 CCX configuration on one die. This ensures the game encounters the number of cores it was truly designed to handle. Please note that Game Mode does not disable SMT.
• We tell the OS to use a Local Mode (NUMA) memory, which keeps a game and its memory footprint inside one CPU die and the locally-connected DRAM. This minimizes several key latency points in the system, which most games love.
I want to add something to this: and when a newly launched AAA game doesn't work, the community won't stop until it does.
My own personal examples: Halo MCC and Doom Eternal. They wouldn't launch out-of-the-box, but people just wouldn't stop trying. The GitHub issues for these games were enormous, full of information and people trying things. It's pretty encouraging.
If you go to protondb.com and search for the game, there's a link under the title for "GitHub Issue Search". I suspect that's where you'll find the discussions. Here's the issue for MCC. https://github.com/ValveSoftware/Proton/issues/2907
What others said, it's in the issues section of the Proton repo in GitHub. Sorry about that, I was on my phone and in a hurry so I couldn't add the links.
Sadly most games nowadays comes with multiplayer as the main product, so that anticheat engines are a necessity to make the game fair for everyone. Those aren't friendly to Wine/Proton, therefore I try to stick to mostly single-player games.
With the kids of how life is going faster everyday, I cannot afford to play on long stretches of time, and being unable to pause on a multiplayer game on a whim (which makes sense) makes it logical to go with a single-player game, as I can simply pause the game and pick it right up when I can, on my own schedule.
I'm glad that Valve is doing that kind of work, it benefits everyone.
One of my biggest frustrations with modern gaming is the lack of single payer games, everyone focuses on Multiplayer, I have zero interest in playing with others,
I play games to escape from people.... People suck, I do not want them in my games
The cynic in me just thinks that it saves the game developers from the need to develop good AIs.
Perhaps it's just my style of video gaming... I play games to relax, definitely not to compete. People sometimes get so wound up in these games, it's supposed to be fun!
So, yes, if a game is multiplayer only, it's a reason for me not to play.
I'm pretty much a single player gamer, but lately i've been getting into the multiplayer side of dark souls. Personally, I think it's my new favourite multiplayer system.
It's focused around co op and invasions and is built into the story enough that it just feels like part of the game, while again not being forced in any way.
It's entirely optional to the point where being able to invade more than a limited number of times is locked behind an obscure, difficult route in the game that's missable and entirely unlikely to be discovered the first playthrough.
There's a few different invasion mechanics based around in game covenants that provide different game experiences, both in single and multiplayer that are a lot of fun. Coop's pretty fun too. It's a pretty awesome feeling helping out another player with a boss or area they've been struggling with and I'm not ashamed to say I needed to summon a bit of help for Ornstein and Smough the first time.
But, my favourite thing I think is the asynchronous multiplayer. The notes and specters. You can leave notes with predefined phrases for other players that can be helpful, or not as well as getting small glimpses of other players 'ghosts' as they play the game, or die horribly to something.
There's no other actual interaction between players though. You can't message people, there's no lobbies, it's all very ephemeral and unnoticeable and just feels like part of the game. The only thing it really reminds me of is the counter-op mode from perfect dark, which was a hell of a lot of fun, even if it seemed a bit lacking at times.
Personally I'd love to see this system recreated and improved in other games. It's the first time i've been interested in multiplayer gaming since I was a teenager playing StarCraft and diablo.
I know someone who regularly plays grand theft auto online. Whenever i've watched them play lately I can't help but think how much better it would be if they'd built a similar system. The game would be perfect for it. The online mode it has seems pointless and pretty lazy by comparison.
I exclusively play single-player games (mostly AAA) and I still have more
games than time to play. But I remember having your feelings when I
only had a PC. Get additionally PlayStation+Switch!
Hey, I have a project that might be of interest to you. It is called the StarCraft Human 'N' AI League, and it is a client that lets you play against custom AI written for the game. It is single player, and provides a challenge without the frustration of griefing idiots on the ladder. Here you can check it out(it's free)
https://schnail.com/#/home
There are a lot of AAA and indie focused single player experiences, what kind of genres are you into? The recent Tomb Raider titles are pretty good for example.
If you like big single player RPGs then boy are you in for a treat...
Single player gaming is better than ever, and even a lot of the "indie" titles probably have bigger teams and budgets than games from whatever "golden age" you're probably thinking of.
Those three are great for relaxing after a long day
FTL: Faster Than Light
Zachtronics games (TIS-100, Shenzhen I/O, Exapunks)
FEZ
Portal / Portal 2
XCOM
Deus Ex (Super old but quite good, I started it recently. I had best results in Proton selecting the software renderer in the first launch dialog instead of DX9)
Grand Theft Auto
Assassins Creed IV (I had trouble running this under Proton though, had to use Windows)
Planetside 2 is MMO but you can play singleplayer. Windows only unfortunately, but there's nothing else like it.
> Deus Ex (Super old but quite good, I started it recently. I had best results in Proton selecting the software renderer in the first launch dialog instead of DX9)
I recommend Deus Exe [0] for playing Deus Ex. And yes, it's still an awesome game.
For me it is not about competing or beating anything.
I do play alot of simulation games, like Cities Skylines or Stellearis.
When I play first person shooters, I just like to run around and blow things up, I rarely "finish" the campaigns, for example Borderlands, Just like to run around the world and see how much destruction and havoc I can cause before I die, then start over...
I am not a completionist, I have no strong urge to "win" or "finish" the games....
I is just a way for me to turn my brain off for a few hours and escape the real world
Can you name one game, electronic or otherwise, that doesn't involve "beating" something, whether it's the other player, the rules, or even just random chance (dice rolls)?
I honestly can't think of any. If there are no goals (and goals imply obstacles to be overcome in pursuit of them) then you've got a toy, not a game.
>They may not be "games", but titles like Gone Home are still video games
They may not be games, but they're still games? I think whether or not Gone Home can be considered a game is highly debatable. I haven't tried it, but it seems that the elements that make a game a game are missing.
That it's available on Steam is completely orthogonal to whether or not it's a game.
I'd strongly recommend looking into the Aesthetics of Play[1][2]. It's a framework that talks about eight primary reasons why people play video games, and only one of those reasons is "Challenge" (i.e., beating a goal). Games like Gone Home, Animal Crossing, The Sims, Minecraft, etc all reflect different play aesthetics, and are intended for people who enjoy different things than pure Challenge.
The expression "video game" came to be understood as much more than "games played through a video system". Even titles like Skyrim, RDR2 and Uncharted thrive much more on the role playing fantasy or on the narrative than on beating a system. These aren't just dressings anymore, like the medieval motifs on Chess, they are the reason we play those games. So yeah, the word "game" expanded its meaning, this kind of thing happens with language.
I'm curious what you are trying to get out of gatekeeping what a game is? Would you not consider children pretending to be someone else to be playing a game? What bout LARP [0]?
However Gone Home would even satisfy a definition of a "game" that requires there to be challenges. Much of the information is hidden throughout the house, requiring the player to find it and reconstruct the whole story. There are even locked off areas that you need to find keys for.
you are not playing "against" the simulator.
you are playing "with" a simulator.
the definition of game is "an activity that one engages in for amusement or fun." => it does not require win-conditions. i prefer games that allow me to be creative. having lose-conditions interferes with that.
Minecraft creative mode. I love building out huge glass towers full of water, long roads made of sea lanterns just under the ocean connecting the landmasses, hollowing out trees putting beacons in the center, etc. None of that involves scores or defeating opponents and it’s one of my all time favorite gaming experiences.
"The Stanley Parable" and even more so its followup, "The Beginner's Guide". Both are technically video games, but actually more like interactive movies.
Epic is kind of a thorn in the side for me when gaming (on a Linux distribution). There are a few Epic exclusive games that I'd like to play (Arise: a simple story, Journey, etc.), but they don't even have entries in protondb.
That's probably due to Epic not having a launcher for Linux. A few months ago(?), I read it had become possible to run the launcher through Wine, but I don't think that's changed anything on the porting side.
I worry that games which are released as Epic exclusives may fall by the wayside when/if they eventually become nonexclusive.
I really miss user server hosting. Stuff like custom maps, or weird custom rules. In a case like this, users couldn't stop cheating, but they could at least triage who is allowed on the server and who is not.
Correct me if I'm wrong but anticheat engines, the way I believe they are currently designed, use their proximity to the actual hardware and OS to work, and the layer of abstraction introduced by Vulkan ruins this.
What if the anticheat model was changed to one that detects statistically-improbable scoring (basically, a scientific model)? And triggering that would require some sort of skill verification, almost like a captcha, but for human FPS skill or whatever, generated dynamically?
Basically giving up knowing "with absolute certainty" whether there is cheat software installed or not
Nearly every anticheat system already does this. The thing about anticheat teams is, they almost never talk about how their systems work, but I can practically guarantee to you one thing: There is no idea you could have which has not been tried in the war against cheaters.
CounterStrike has, in times past, probably also today, used where you're aiming as a signal for whether you're using wallhacks. Like, if you're aiming and trailing directly on top of another player, but through a wall, for extended periods of time. This is statistical modeling.
> And triggering that would require some sort of skill verification
How do you remotely validate the skill of someone who is possibly cheating? Why wouldn't they just cheat at the validation? Do you, maybe, accept that they may cheat, but then raise videos of their skill checks to an enforcement team for validation? CounterStrike also already does this! They have the Overwatch system which enables specially trusted players to review gameplay footage of other players which VAC suspects of cheating.
Now, Runescape is the most explicit example of these "skill checks" I've encountered. Certain undocumented behavior which resembled botting could trigger an in-game "captcha" where you had to prove you were human. If you were, you'd often get a prize. Simple. Somewhat effective (often, people would just get around this by paying cheap labor in third world countries to oversee a hundred bots per person, and solve the captcha events when they happened. they did not save Runescape's economy from being destroyed by bots, and eventually, the game began enforcing strict value-for-value trading rules between players).
What are CounterStrike and Runescape infamous for? Cheaters and botters, moreso than most other games.
Statistical methods are a tool in the toolbox of anti-cheat systems, but they're not enough alone. They're far, far too easy to defeat; when a metric becomes a goal, it ceases to be an effective metric. If I keep a wallhack on for an entire game, it becomes very easy to detect; If I turn it on for just one kill, that one kill which puts us on the winning side of a tie, and I'm victorious, the outcome is similar, but I'm far harder for statistical modeling to catch.
There should be a very small percentage of exceptional players.
If you allow everyone who cheats to play, even if they're only playing at the peak, it will break the balance of everything. The top tier games will suck because half the players are cheaters, and the lower tier games will be filled with aimbot smurfs on their way up.
Unfortunately pretty soon we are going to enter a world where the cheats can be deep learning based and entirely external to the game itself (only using video as input, transmitting raw mouse input, etc). It will be fundamentally impossible to tell the difference from human players. This will be a weird time for competitive games when it happens.
In that circumstance if we had really good auto match making, does it matter? In a competitive environment I don't care if I'm vs.'ing a bot or a human as long as I'm matched with the intent of 50% win rate.
Of course with current cheating the issue is not deep learning based agents but seeing through walls or aim assisting. Those just ruin the enjoyment of the game. Similarly I loathe vs'ing an AI that uses the same methods.
Ah, sorry about nomenclature mixup. I love it all!! I want to see Linux become the premier “gaming OS” because gaming shouldn’t depend on a proprietary OS
The plan is basically to use these translation layers on top of MoltenVK[1], so the stack goes like [Game -> DX11 -> Vulkan -> Metal].
The other option is for Apple to pull their heads out of their asses and support the cross-platform graphics API that everyone else does. But we can all guess how that will go. If you want a platform for gaming, stay far, far away from macOS.
It sure is amazing currently, but I fear in the long run nobody would even bother to make native Linux versions anymore.
It's such an easy out for developers. Why bother when people will make it work on Proton somehow and you don't have to promise anything nor do Linux support.
The other side of that debate is that Proton would bring more people to Linux, and therefore the incentives for a good native version of the game on Linux would be a lot higher.
If you count "switched to Linux" as including "finally stopped propping up the grungy old Windows partition", then mark that down for a sample size of two.
While you're right, I'm kinda OK with Windows becoming/staying the main PC gaming "API" that more than one operating systems implement. It's just gaming; the important things are fun, challenge, immersion, escapism and great stories. Not how pretty it is under the hood.
My "based on porting windows" comment was based on my understanding that SDL started with windows.
Wikipedia says: "Sam Lantinga created the library, first releasing it in early 1998, while working for Loki Software. He got the idea while porting a Windows application to Macintosh."
Even the naming of directmedia suggests microsoft roots to me: direct3d directplay directx, etc.
But my larger point was that I don't know how you would create a "native linux" game - I think high-functioning games on linux use cross-platform toolkits of one type or another.
I don't know maybe you could cobble something together part wayland, part mesa, part pulseaudio, part v4l, part /dev/input...
At the end of the day anything that runs on Linux without needing additional compatibility tools is native.
You could make a distinction for Windows/whatever games bundled together without Wine/eON/whatever and depending what want to determine that might make sense but at that point you probably also want to exclude things like Unity that don't really do a great job at integreating into the Linux environment.
SDL can be used for porting games (ie, making them native) and that's what it was originally created for but it's not really comparable to bundling a Windows .exe with Wine, which would add a lot more complexity.
Ideally games would have native Linux versions. Practically, no one did this before Wine/Proton because the Linux market is so small and bug-prone, so the choices are Proton or no games at all.
I think the major change was Steam and the Steam runtime rather than Proton, which solved the library fragmentation problem. Since then we have seen a considerable amount of same-day releases and native ports on Linux.
It didn't solve library fragmentation as much as it showed the solution that was always available and already used by most ports before the Steam runtime existed: to bundle all the libraries you need besides system interface like libc, libGL, etc. This is really no different on Windows.
> Practically, no one did this before Wine/Proton.
Oh come on, that's a huge exaggeration. There are thousands of native games available for Linux and Wine/Proton had nothing to do with that. Finding something to play hasn't been a problem for a long time if you are interested in a wide enough range of games.
Steam did make a big contribution to that but that was before Proton - if anything, Proton might have slowed down the number of new native releases. What Proton solves for people is being able to play specific games they want to play, like for example the latest popular AAA game that everyone is talking about - for that it's not enough if there are x% of games available no matter how big x is.
It's a chuckle-worthy thought now, but I am willing to bed it will be reality for backward compatibility with historic games in the long run - cf. the use of DOSBox to run old DOS games in modern systems. Countdown to old Windows games delivered in full Linux containers starting now ...
You think people will take games that already run on windows and package them in a linux container that runs them with wine, then require the multi gigabyte widows linux subystem to be installed so they can run through that?
You are willing to bet on this? How much would you like to bet and are there any other bets you would like to make? Maybe the cubs winning the super bowl or dial up modems replacing fiber optics?
The example I gave was old DOS games that no longer run on modern versions of Windows and are easier to ship with a bundled emulator - and that emulator is a free software reimplementation of the original thing. I think it's very likely to happen again in future iterations of the same principle, yes.
I'm not talking about the DOS games at that point (it's a reference example for a pattern, as mentioned), but newer generations of games and the basic principle of operation. There are already some older ca. Win 98 era games that run better on Linux+Wine than on Windows past Vista due to compatibility problems, and I do think it'll eventually become a commercial reality to sell those kinds of games packaged into a a Linux VM once their numbers increase, yes.
It's easier to test, doesn't require costly porting work if it already works, VM tech is increasingly commoditized, low licensing costs, the performance overhead won't matter, etc. Just like no one notices today if a DOS game is sold bundled with DOSBox.
The alternative would be to maintain the native Windows port of Winet that's effort - I bank on laziness with the VM bit. The fact that WSL went VM from 1 to 2 is an indicator of viability for the general idea of transparent virtualization, too.
Honestly, if you take this another round I have to assume you're being intentionally obtuse for trolling purposes.
> Honestly, if you take this another round I have to assume you're being intentionally obtuse for trolling purposes.
You said you would bet that someone would use wine to deliver an old windows game on linux that runs inside window's linux compatibility layer, doubled down, and say anymore who says that is nonsense must be trolling.
Do you think that maybe instead of being likely to happen, it is likely to never happen due to wine being open source? It could just translate to a modern windows API instead of Linux. There is even something called reactOS that is an open source and windows compatible.
> Do you think that maybe instead of being likely to happen, it is likely to never happen due to wine being open source?
That's what I meant with the last paragraph. Linux doesn't come with a licensing cost; maintaining a working "Windows backend" to wine is effort. Just bundling with Linux seems lower effort and cheaper. Cf. also just about all of the system containerization trend and what's driving it - and it's in part API surface between the delivery and the system.
None of the recent AAA games work. By none I mean not 99.9%. Proton is not a relyable solution to play games on Linux, it workish on old games and even the one that work have really annoying issues that you woudn't have a on Windows.
On top of that you add the bad stability / performance of graphic drivers on Linux vs Windows.
Edit: Since I'm being downvoted show me recent games that work without issues / tweaking etc ... ?
Number is completely wrong. Most of them work. Just go through the release list and look at their protondb entry. Doom Eternal, Wolcen, Resident Evil 3 - the three newest games on Steam Computerbase looked at and they all work.
Proton has been fantastic for me, it finally gave me what I needed to reclaim my Windows partition and go full-on Arch! In some cases, running the Windows version inside Proton has actually worked out better for me than the native port (Dead Cells, for example. The native port crashes the Steam overlay and lacks Steam Controller support, but running the Windows version in Proton is seamless)
I highly encourage you guys to check out the tech making this possible: DXVK. It's incredible what you can do with these lower level APIs. I'm not sure if this is the right word, but "meta shader pipelines" like this are absolutely the way of the future in emulation. See also: Dolphin Ubershaders.
Keep in mind most "native" ports are just crappy, but official, wrappers that just do what proton does but worse. This is why you will see a lot of native ports perform worse, they weren't really native in the first place.
I'm gonna blow your mind: the word "native" doesn't actually mean anything in this context. The only thing that matters is official support from the developer, regardless of the technology used.
I was explaining how an official port could perform worse than an unofficial one, so yes "native" would absolutely mean something in this context. It's commonly understood that using the native system interfaces would usually be faster than using a compatibility layer.
> The only thing that matters is official support from the developer, regardless of the technology used.
The only thing that matters for what? I'm not sure what point you are trying to make.
The implication from the comment was that Wine is better at running old Windows games than Windows itself. I’m not sure where this Linux vs. Windows comparison is coming from.
No, you mis-read. chaorace said that Windows EXEs running in Proton gives them better results than running the Linux binary that the game developer ships ("native"). AnIdiotOnTheNet stated that Windows APIs are more stable and better documented than Linux APIs.
As a long-time Linux dev (see my profile), I have also found this to be true. Linux userland APIs are unstable and change all the time. Some transitions that come to mind that have affected me personally: ALSA->pulse; libudev->libudev2->systemd; gstreamer 0.10->1.0. All of those changes required modifications to my software, and the backwards-compat tools that are provided are buggy and insufficient. Meanwhile, you can still write and run winmm[1] applications on Windows 10, and they will work in almost all cases. It's simply the case that the win32 API is more stable than Linux userland APIs, so it's entirely plausible that games will run better in Wine, which shares that stable ABI, than they will on Linux, especially as time goes on and Linux userland shifts yet again.
The audio subsystem changes definitely could have been done better. Ideally /dev/dsp should have been extended like has been done on the BSDs instead of inventing completely new interfaces. That said, doesn't libasound still work with pulse?
gstreamer on the other hand is something you can just as easily ship yourself. I wouldn't consider that a Linux userland API as much as a random library that is present on many Linux system just like some crap you'd find in system32.
I'm less familiar about the API/ABI changes in the libudev transition - is there anything there that broke API compatibility.
The "lower level" userland libraries (glibc, libGL, libX11) tend to be pretty good at maintaining backwards compat. Well, except for Mesa pulling in the C++ standard library which can be a real problem when older games also dynamically link (incompatible) versions.
I've been suspicious of user-led development (e.g. open source), expecially Linux. Its popular to put in new features; less so to test, endure backward compatibility, control user experience. So it doesn't get done (much) in Linux.
My cohort have a phrase they attribute to me: Linux is not ready until they get the 'Have Disk' dialog.
Eh, I don't agree. Linux has been "ready" for my usecase for more than a decade. There's pros and cons to each certainly, but I find Linux much more pleasant to use than Windows, and I like actually being in control of and able to modify the software I run. Until I can do that, Windows is not ready for me :)
Right. But the point is the vast, vast (non-HNer) use case is not in favor of Linux. For every 1 Linux-on-the-desktop person, there are what, 1M others?
Only because the disto does it for you. If they mean because the driver is distributed from a centralized repository over the internet... that's how it works in Windows too, only Windows also has the option to use alternate media and a stable enough driver ABI to have that make some kind of sense.
I don't know if API stability is a barrier to adoption or not, but I was just explaining my experience with both platforms. For me, I don't much care how many people use Linux; I just want to use my computer how I like to, and Linux suits my needs best.
> (Dead Cells, for example. The native port crashes the Steam overlay and lacks Steam Controller support, but running the Windows version in Proton is seamless)
Suggests the comment is about running the Windows version under Proton being a better experience than running the native Linux version.
Both are correct. Some native ports run better under Proton because the port sucks, but I recently saw a video where they compared Doom Eternal with Proton vs running native on Windows, and the Proton version ran better than the Windows version running natively.
It would be interesting to have some analysis digging into potential causes for this result. As someone who was recently surprised at how much impact a CPU upgrade (G3258 -> 4570 on the same LGA 1150 motherboard [1]) had on overall performance even in older indie titles where I wouldn't have expected it to matter much, I would be curious to look at what background services are running, what their cpu/memory footprint is, and how well the OS handles scheduling them.
Even without the obvious pigs like virus scanner, printer utility, launchers for other storefronts, various chrome-embeds like Slack and Spotify, I wouldn't be surprised if the Linux desktop does a better job of this.
The most common theory is that it's the Denuvo anti-piracy software. It's known to cause performance drops on Windows, and it often has to be bypassed or disabled in Linux games.
Ah, the parent comment is actually correct here. Dead Cells is a modern release with a released Linux port. Unfortunately, it isn't interacting correctly with the Steam overlay API and the issues haven't been fixed for months. Running the Windows version via Proton, ironically, is a more stable experience for my use-case.
Ditto here. My wife's PC, for example, is now running OpenSUSE full time. She used to dual boot with Windows 10, primarily for games, but she would spend most of her computing time using Windows just because of the game inconvenience. Now pretty much everything she plays 'just works' with Proton, and she has no need for Windows.
Also Tomb Raider 4 uses DirectX 7 which is not supported by DXVK so you'd need to combine it with dgVoodoo2 [0] to translate DX7 -dgVoodoo2-> DX11 -DXVK-> Vulkan, which did work quite well for me with Tomb Raider 4 and 5 while Wine's DirectX 7 implementation had rendering issues at the time.
Last year I played Final Fantasy XV coop with my friend. This game is a part of Nvidia's The Way It's Meant to Played, there's even Nvidia logo on the start screen. I had a lot of crashes on my GTX 960. Almost no problem on Radeon (although multiplayer is quite bugged-ridden there).
Sometimes official support tells nothing about runtime quality.
And yet, I still have trouble running normal software that was built for Linux, on Linux.
Every set of updates might cause a problem that I've never seen on Windows or a Mac. I had an Ubuntu machine that only lasted 2 weeks before it wouldn't boot one day after an update. Never figured that one out - it was an experiment to see how much easier Manjaro was to setup and add software to than Ubuntu. (The answer: it's much, much easier.)
I just checked and it turns out it's running natively not via proton.
Not sure if any of this will be news to you, but for generally debugging:
If you run `steam` from a command line, and then launch civ 6 (or any game) from steam, it will print any errors to the terminal. Chances are it's some sort of missing dependency.
I was told by someone else that I might need to set launch options to `LD_PRELOAD=/usr/lib/libfreetype.so.6 %command%`, for whatever reason I didn't need to, but you might try that.
You guys are the best, I had gone through all the debugging steps awhile ago including what you put there (which was required for me). But the culprit to it not working was having some mods enabled that disabled the menu when running on Linux. Thanks for getting me to take another crack at getting it running!
I don't play civ6, but I've managed to play quite a few Windows games on Linux with Proton, Lutris and before that with Wine.
The two most important factors for a game to run well are 1) the version of Wine/Proton you're using and 2) the version of your GPU driver you're using.
Rolling release distros like Arch are great for gaming, since you always have the last version of Wine and of your GPU driver. It's a real pain in comparison on fixed release distros like Ubuntu, especially if like me you stick with LTS releases.
By using Proton within Steam Play you at least don't have to worry much about the version of Proton; just make sure you've not forced an old release and Steam will chose the right one for you. Same when using Wine within Lutris. Your only remaining duty is to make sure you're running up-to-date GPU drivers.
It apparently does, I just assumed that it was running on proton since I was having issues with it. But the culprit to it not working was having some mods enabled that disabled the menu when running on Linux. Thanks for getting me to take another crack at getting it running!
I was unaware, I just assumed that it was running on proton since I was having issues with it. But the culprit to it not working was having some mods enabled that disabled the menu when running on Linux. Thanks for getting me to take another crack at getting it running!
Proton has been a game changer for me: after many years on Linux only I ended up building a gaming rig a few years ago as I wanted to get back into gaming.The plan was to dual boot and only use Windows for gaming, but in practice rebooting all the time is just too much of a pain so I was using Windows almost exclusively there, with all the related frustrations. About 6 months ago I got myself a new SSD and made a fresh install of Linux with steam and Proton and I've been amazed a the performance and game support. Of course not all games work out of the box (and some not at all), but I haven't had to boot to Windows in months. And for the games I play the frame rate is at least as good as what I used to have on Windows (on a couple of games I do get occasional drops, but nothing too distracting). I play a lot of Assetto Corsa Competizione and my G27 steering wheel even worked out of the box!
In other discussion someone pointed out about passing a gpu to a windows kvm[1] and getting the output back to linux[2]. I never tried but seems really promising, might try it someday
> The majority of the games do not support multiplayer on Linux, due to dependency on Windows-specific anticheat software.
Definitely not majority. Maybe majority of the top 10-20 most popular/most cheated games? The very long tail of games works with multiplayer splendidly
> Many, many of the games themselves aren't totally stable on Linux.
https://www.protondb.com/ is a great database to check on the stability of games. Many, many games are very stable. Games that I happen to play regularly are more stable than Windows (especially with alt-tab and such).
I wouldn't oversell protondb since it's based on user submitted reports. I've tried multiple games that were rated platinum, but wouldn't launch or had other graphical issues that made them unplayable. Luckily the issues usually present themselves before you reach the 2 hour refund time limit.
I feel like Proton is Valve's bid to free themselves of their dependency on Windows, so I like to think #1 will change in time as the publishers come around to the idea that Windows is slowly but surely losing its position as the only viable gaming platform.
I think SteamOS and/or Steam-Machines were that bid. Both seem to have been deprioritized and now Proton is a fallback.
I'm sad to say that Windows will likely stay this way for the foreseeable future. The additional test/QA work required in order to make additional platforms (linux, macOS, etc) have to have a business case associated with them. You could imagine the developers writing the game on linux, building and debugging/running locally on linux, but testing and shipping on windows. So even if the games work well on linux, they won't necessarily get a release.
The only thing that might change this balance would be if somehow PC-style games would target Android, or if Android would somehow become some kind of desktop OS. Both seem infeasible to me now but something could change.
> 1. The majority of the games do not support multiplayer on Linux, due to dependency on Windows-specific anticheat software.
Not even anti-cheat, just different implementations of things in the Linux and Windows versions. IIRC Paradox games don't have any strong anti-cheat, but Linux and Windows users can't play due to how their systems handle network time synchronization.
> 2. Many, many of the games themselves aren't totally stable on Linux. So, expect a crash or two at critical gameplay moments.
Many, many of the games themselves aren't totally stable on Windows, either. Bethesda games (Fallout, Skyrim) come to mind -- desktop Skyrim had all sorts of bugs and crashes on Windows.
And why would it crash only at critical gameplay moments? Sounds like FUD.
Modern Paradox games (see Stellaris and Crusaders Kings 2) do support cross-platform multiplayer^. Maybe you are confusing them with Civilization V/VI, which did launch without cross-platform support and it is broken periodically due to the Linux/Mac version lagging behind the Windows one after each major update.
^ Aside from the regular out-of-sync issues they suffer sporadically, no matter the platform.
>> Microsoft can change DirectX whenever they want
They really can't. Software that uses DirectX will require a specific version of DirectX in order to have the correct ABI so that it can dynamically link against the DirectX libraries. Those versions and therefor ABIs are set-in-stone. Not to mention that a huge cross-section of the DirectX software library also distributed the required version of DirectX with the software.
Microsoft can change any FUTURE version of DirectX, but the deployed versions in the wild are out there and can't be changed.
I wonder if Microsoft has a cross platform .Net Core-like DirectX in the works. Given their push to unify their Windows and XBox gaming experiences, I can't imagine it'd hurt to spread that out even further and expand to capture as many games as possible. Though I guess outside the other consoles there's not a lot of other game systems.
I would not be surprised in the slightest if they did that. In fact, they've actually tried that before: https://en.wikipedia.org/wiki/Microsoft_XNA. It's discontinued, but still used.
MonoGame implements the XNA API and lets you write games that run on Win32, UWP, macOS, Linux, iOS, Android, Xbox One, PS4, PSVita, and Switch. That's probably the best cross-platform support of any game framework.
> Create a standard, ask Unity and Unreal Engine to support it
It's called Vulkan, I believe. Or, you know, OpenGL even. Doesn't change the fact that it's the developer who will have to support it. Also doesn't change the fact that the developers _won't_ support it because of the same reasons that they don't now: it's not commercially viable. DirectX is not the problem.
Graphics is not the primary problem. The DirectX family of APIs also supports audio, input, networking, and other useful things that are in many ways far more difficult to make work across all platforms, at least historically.
So in some sense, DirectX's existence changes the economic equation, which does make it part of the problem.
Yes and no, there are new APIs to support the same use cases, and none are standard/cross platform. Whether they are part of DirectX formally or not is not important.
While XAudio2 is a key library, it is not DirectX one, as we were talking about DirectX umbrella project. It is not as low-level library as other DirectX projects were anymore, it doesn't talk to the hardware directly. It is really just a user space library with convenient functions, made by Microsoft. It also has competition, there's OpenAL, which is similar - even if it doesn't have as nice API, it is cross-platform.
Yeah, I understand, that is why I said it is not DirectX, but being in DirectX or not is just marketing.
The reason is that XAudio2 (and lower level ones and other non-audio ones) is developed, distributed and recommended by Microsoft, and it is used by many major games and audio engines.
So I don't understand who cares about whether it is formally part of DirectX or not.
I didn't claim there aren't alternatives like OpenAL or Wine's XAudio2 implementation. I simply said the original XAudio2 is not portable on its own, which means you cannot simply use it in Linux, for instance.
I share your criticism, but just "Create a standard" is maybe a bit hard to do. Game devs need a market. The linux market is not really the biggest one, neither in numbers, nor in money. It only became a bit relevant, because Valve used linux, to threaten Microsoft, as they tried to get a big cut of game sales, with their own market. So good for linux, yes, but the normal linux game market is still quite uninteresting (mildly put) for publishers.
> I share your criticism, but just "Create a standard" is maybe a bit hard to do. The linux market is not really the biggest one, neither in numbers, nor in money.
I know of at least one game that's regularly in the Steam top 10 (Path of Exile) that is doing a port from DirectX to such a standard, Vulkan.
Not to support Linux, but because Vulkan is cross-platform, allowing them to reuse their code base for a mobile game, and also to be able to potentially support things such as Stadia. They also said this will lead to a mac port and may lead to a Linux port.
So there might actually be incentives already for game devs to use cross-platform tech, which could lower the barrier for Linux ports significantly and make it worthwile.
Sure thing, and they are not the only one. And it is good thing. Star Citizen for example is a very big one, who will use vulkan (so probably around 2030+, when the game is finally somewhat finish ...)
But my criticism to the comment above was about "just create a standard" for the linux world, as it is something trivial to do. But yes, with vulkan there now exists a standard for graphics, that can compete with DirectX again. (even though linux-foundations are not really involved directly in the Vulkan standard)
But games are more about the graphic layer, because with OpenGL there was a graphic standard before, yet still allmost no one bothered to port to linux.
That changed, for various reasons. (mainly Valve and Android, I think). Also it helps, that unity for example can target linux, and their editor also now runs on it (but I don't know, how well).
The thing is it's not that hard to write cross-platform games. Compatibility layers like SDL2 make it easy to target a platform agnostic system interface. Vulkan enables high performance graphics on most platforms.
Just out of curiosity, do you speak out of first hand experience, that it is not hard?
When you sell a game, people expect it to just run. Windows only games have already countless bugs, making it impossible to start for quite some people. Now add to that Android (with all its different versions and vendor specific implementations) Apple with a slightly different ecosystem .. and then Linux Desktops.
Lets just say, that I am making a game. Even open source. And I want cross-platform, but don't want to get mad along the way and I want to focus on the gameplay and not platform specific code. (and did not want to use unity for various reasons)
> And I want cross-platform, but don't want to get mad along the way and I want to focus on the gameplay and not platform specific code. (and did not want to use unity for various reasons)
Which platform specific code? With a compatibility layer and a cross-platform graphics API we're talking about a vanishingly small amount of code.
"Which platform specific code? With a compatibility layer and a cross-platform graphics API we're talking about a vanishingly small amount of code."
Again, do you have really first hand experience, how "vanishingly small" that amount of code is?
I have not much experience in that area, as I specialiced on the web years ago, BECAUSE I heard too much horror stories about the difference in "theoretically cross plattform" and reality.
I have not released a commercial product, but I have worked quite prolifically with these tools and the experience is very good.
Web is an interesting value proposition because somebody else is worrying about portability, but it's quite limiting isn't it? I mean you're limited to webGL and a single-threaded host environment. It's certainly possible to make some nice experiences within those limitations, but you're not getting anywhere close to the full capacity of a user's hardware.
Good luck, if you do. I am serious. I also think the waste of the millions of layers of the web to the hardware disturbing, but it is the best compromise I see.
"but you're not getting anywhere close to the full capacity of a user's hardware. "
Certainly not. So no, doing a graphical bombastic AAA game is not possible, but the vast majority of games is today quite doable on the web.
"a single-threaded host environment"
And fortunately today this is not true anymore. With web workers and various other approaches, you can have costly calculations in the background, but sure, this is still not the same as real multi-threading.
ProtonDB had that issue in the beginning when users selected their own rating, but they changed the rating system. The only complain that could remain is the one for the multiplayer - if the single player runs perfectly but the multiplayer not, which rating is that? But pure multiplayer games are rated correctly, see https://www.protondb.com/app/578080 for example.
Doom Eternal while it works pretty well does have significant artifacts in some levels. There is also some weird bugs that don't exist on Windows and significant performance drops (game goes into single digit framerate) which again doesn't happen on Windows 10. Doom Eternal needs a high framerate to be played properly. I have a 1080Ti, I shouldn't have frame drops.
I been playing a lot of Doom Eternal (clocking over 40 hours in game) while in Quarantine and I've played it both on Arch Linux and Windows 10. My rig is pretty good (Ryzen 7 3700X and a 1080Ti).
Also if you have kernel.modeset=1 as a kernal parameter on to get Wayland with Nvidia, proton just doesn't work as it can't load up the vulkan libs (this is me going through the steam logs). I believe Pop_OS! does this, however I switched to Arch Linux now.
So I have to choose playing games with screen tearing while scrolling in Firefox or smooth Firefox with no-games.
Nontrival answer to a nontrival question. your first order goal, gaming on linux, has a dangerous second order effect - removing microsoft market. even if you could magically solve all the problems to make a technically sound widely adopted gaming mechanism on linux, id bet MS and/or Apple take an interest in shutting you down one way or another.
Linux server is perfect because there is huge commercial demand for it. Linux desktop has problems because there is almost no commercial demand for it. Good things require money because effort isn't free.
ChromeOS is a great demonstration of this. A polished, solid, very good desktop experience based on Linux because a large company has a vested interest in its success.
The Linux desktop is perfect for some goals and situations, this however, has nothing to do with that. Having issues while running a game on a platform it was not written for says nothing about the quality of Linux as a Desktop OS.
Being a sysadmin for 15 years and a Linux desktop user for 18+ years, I can say that the requirements are vastly different after a certain point in the OS.
The crux is making users do everything they need without accessing the parts they shouldn't.
In the 90's that situation was flipped: it was the desktop side that was stronger and the server side weaker. This was mainly because it was a bunch of hackers making the system they wanted for themselves. But then businesses started being built on Linux pouring money into server-side development (adding features, fixing bugs, improving performance etc.) and many of the hobbyists decided it was time to get paid for their efforts. So you end up where we are today.
Personally I've had less issues with the Linux desktop (KDE) than with the Windows desktop (outside of course of dumb things I did myself, like messing with GPU setups, or removing a vital library for rendering).
I hadn't heard of Proton before and the article doesn't explain. Here's what the GitHub repo for it says [1]:
> Proton is a tool for use with the Steam client which allows games which are exclusive to Windows to run on the Linux operating system. It uses Wine to facilitate this.
My question is, what's the "secret sauce"? If this is in fact that much more successful than Wine, what's different? Is Valve putting lots of dev time into it? Or is it just pre-configured for ease of use?
In addition to the what others have said (DXVK, pre-configured WINE, D9VK), the Steam client integration is also a MASSIVE quality of life boost and a serious lowering of the barrier to entry.
With Proton, the Windows versions of games appear in your library [1] and you just click to download and install [2]. And then that's it! No faff, no managing wine versions. If someone is intending to play a whitelisted game then for all intents and purposes their UX is exactly the same as playing the game on Windows - which is to say "very straightforward".
[1] By default only whitelisted games appear. While this whitelist is expanding, it's also possible to enable Proton to automatically run for all non-native games.
[2] A warning window will pop up to inform the user that a compatibility layer is being used, but otherwise it's identical.
>[1] By default only whitelisted games appear. While this whitelist is expanding, it's also possible to enable Proton to automatically run for all non-native games.
Or better, enable it for the game you want to try. Properties -> use compatibility tool.
This also allows you to use different version of Proton for different games (e.g. it's fixed in a beta build or broken in the latest build) and to enable Proton for games which have a native version!
In my experience, random non-whitelisted indie games work pretty great. My guess is that the average small shop is using more 'default' tooling with less custom engine stuff, meaning things are more likely to work under proton out-of-the-box than a giant AAA megabeast.
(I've had very similar experiences in a very different context with OEM Android. Small manufacturers don't screw around with the OS internals, while big shops (eg, the one rhyming with HamStrung) are more likely to change things in non-obvious ways.)
It's Wine + DXVK (including D9VK since they merged together) + ESync with a different Wine environment for each game. Valve also helped Codeweavers developers to implement controllers support thru Wine.
> ESync with a different Wine environment for each game
This is where Proton was a win for me. It's not super hard to make many of the popular games work, but managing the different wineprefix's or making sure some random DLL is or isn't installed was a pain. Proton keeps 'em clean, separate, and up to date.
I'd be really surprised if there wasn't fixes and configs for a lot of games in Proton, but also that now you at least can install and run Windows games on Linux from Steam. Before Proton, even when I owned a Windows game, I had to pirate it to run it through Wine.
Yes, it will also use a known good version of wine for a particular game. Switching versions manually to find one that worked for old or newer games had been a headache; that work is now done by proton.
To me it seems like a kind of Wine staging, with patches not ready to be merged into the Wine mainline, yet could make some game run or run better.
Over time as the code is proven in production and/or is cleaned up to upstream standards, it can be merged to upstream Wine, reducing the difference.
Also IIRC there are some other pieces that are not (yet?) part of Wine, that are distributed with it, such as the various DirectX->Vulkan translation layers.
It's alot more convenient then wine as it's built into steam. You could get a lot of games working on wine before but setup could be a bit of a pain. With Proton you just install and play on steam like you would with a native Linux game.
Is anyone using Linux + Proton for in-home streaming?
I'm seriously considering to completely ditch Windows 10 and move my gaming to PS4/5 + Linux/Proton, but I still want to be able to stream games from the game PC to the steam link in the living room. Does this work just as well with Linux/Proton as Windows?
Yup.
One recent (well, not recent, it's been like 6 months) issue is that after about 1h30min-1h50min the sound from the PC (XFCE Manjaro) corrupts (starts to crackle and gets worse until unbearable). The only fix I have been able to come up with so far, is to cut the connection to steam link, reset pulseaudio and reconnect to the steam link.
Very annoying issue that's being discussed on Github, but not necessarily addressed, as it's probably very hard to triage.
It works well, yes. However I can't compare with Windows since I don't have any Windows install anymore, so probably you need to get a comment from someone who dual boots!
Yeah I've had it running and streaming! Have run a few games this was - ARMA3, GTAV, South Park: Stick of Truth. All worked well.
Have also tried running the windows steam client in WINE and had a few more issues, but as ever YMMV.
The performance isn't quite as good (very close to windows perf levels), but quite a few anti-cheat systems will not work in Proton (even less so in WINE).
> quite a few anti-cheat systems will not work in Proton
A lot of interesting "hacks" (sorry for calling gaming on Linux a hack) are made impractical by this.
Another is that you can buy a miner's GPU (no video output, but much cheaper) and modify the drivers to route video through integrated graphics VO. Or, modify drivers to support SLI on any nvidia card. These driver modifications require running Windows in a special mode, which triggers anti-cheats. Maybe there's a way around that. Haven't heard of it being attempted on Linux. By the way, these driver modifications are just removing artificial restrictions.
I'm perfectly ok with some games not running as well as Windows, or not even running at all, in particular if I could also play them on console. I was more worried that Proton would not work reliably with streaming at all because it has to go through all these hoops to get an image on the screen in the first place. But it seems this is possible, which is great.
Games with anti-cheat not working doesn't bother me either as I don't play any games online anyway. So the intersection between 'games I play' and 'games that need anti-cheat' is very small ;-)
Hate to be that guy but nobody mentioned it -
Lets not forget Proton is a wrapper for Wine, and we're here today thanks to many many years of community effort.
Yes, Vulkan is awesome, but its biggest benefit apart for performance is DX11+ support.
Wine had DX9/10 for ages now, and many Proton games don't depend on Vulkan to run.
While proton works wonderfully, I've found that most of the time the anticheat systems do not run at all. So multi-player is usually disabled, even if the game runs flawlessly as a port. The Halo collection let me log into Xbox live, but then fails to run anticheat, so you are left with campaign. Same with PUBG.
So many games run extremely well that it's not a deal breaker for me. My last gaming rig was on Zorin Ultimate.
I don't know what rock I was living under, but I finally tried it yesterday after a misadventure forced me to upgrade to Windows 10 to support a new nvme drive.
Tabletop Simulator, The Witcher 3, Endless Legend, all play perfectly. Haven't had the chance to try more.
For me it worked better than Windows for the Bioshock remastered series. On Win 10 the games would crash every few times during saving. I tried every workaround I could find but nothing helped. On Ubuntu the games worked fine.
IMHO "emulating" the (fairly small) subset of the traditional Win32 and DirectX APIs required for typical games might even make sense on Windows itself, should Microsoft one day decide to deprecate Win32 in favour of something more "modern" (heavy air-quotes).
The window creation and input event handling of Win32, together with D3D9 and D3D11 (the really popular versions of D3D), and whatever is the current audio API on Windows (this seems to be the least stable area) have proven to be quite fantastic for games, maybe the best set of low-level APIs needed by games outside of actual gaming console.
Porting those APIs to other platforms, instead of porting the games doesn't seem such a bad idea at all in hindsight.
>"emulating" the (fairly small) subset of the traditional Win32 and DirectX APIs required for typical games might even make sense on Windows itself, should Microsoft one day decide to deprecate
I recently tried to run some WinXP-era games on modern hardware, and had absolutely no luck on Windows 10.
However some of the games ran fine on Wine (and 64-bit Linux).
The only downside I see to emulation is latency, but for many games this doesn't matter, and it's worthy to keep them runnable like this.
There shouldn't be significant latency issues, unless there is large amounts of (CPU) work that's required to make large data structures compatible(for a silly example, imagine that the texture formats are different and you need to convert between them). Or if you need to simulate a single function call in a tight loop with several calls.
But the overhead is usually not much more significant than what you get when you import a library to call OS functions on your behalf, versus calling them yourself.
I don't have a lot of of super current AAA titles, so most of my games that didn't already work on Linux(most of what I buy) already worked on Wine. But with the Proton integration, I do appreciate that I don't have to run a separate Wine instance of steam and instead running my Windows games is far more transparent. I guess the only minor downside is that since the whole process is so transparent it makes it a bit more jarring when I do come across a game that doesn't work.
Well, of course all of that would not have been possible, without the long hard work and experiences of all the people involved with creating WINE in the first place.
That said, I think it's great that Valve contributes. It might be naive though, to believe, that they'd do any such thing, if the license did not force them to. I am quite sure, that they'd see some kind of advantage to take, if those contributions could be limited to only their own platform.
Adding to the anecdata, but steam Proton has been great for me under Debian. I've been gaming on linux on and off for about a decade (mostly with wine before or the few games that did support linux).
Porting games seems pretty hard IMO. Why isn't there an intensive to port the latest Adobe CC software [1] too?
I know a few designers & video editors who use passthrough to run Adobe software on their beefy workstations, which I would also prefer as I'd rather not use multiarch on my linux system.
I paid for a CodeWeavers' CrossOver lifetime license. Their employees contribute to Wine. I don't know what software they specifically try to make sure works, but Office 2016 and Adobe CS6 works very well.
Bingo. If you need Adobe CC and want a unix-y environment then you're using it on a Mac. And there is a cost incentive for Adobe and Apple to make them work.
Valve is expanding into the linux/unix space because Microsoft has set up their MS Store, which threatens to undermine them directly.
While I do appreciate Valve's support of Linux, it's hardly altruism: it gives them some room to negotiate with/pressure Microsoft. (i.e. while it would be painful to push even a fraction of their users over to it, it is an option Valve has) Compare that to the situation app developers on mobile platforms find themselves in these days. So it's smart strategically even if it doesn't translate into big $$$ currently.
I was a ubuntu only user for the last 3 or 4 years. Even though part of what I did on my computer was gaming, there was a side of 3d design which I was put in a bad position when I started to get more hardcore. I decided to buy windows and try it. No regrets W10 is good and universal. I would consider going back if Linux has more cad programs compatibily. In the time being I'm just gonna miss Ubuntu remembering to mute if my earphones are plugged in.
I've only discovered Proton recently and I'm very impressed. I'm no stranger to using Wine to get games running in Linux, but Proton makes the whole process so easy. And Wine itself has come a long way even in the past few years. GTA V was the reason I kept a Windows partition when I played it a few years ago, and now it works amazingly with the latest version of Wine/Proton.
Is steam selling linux games with proton as Linux games? Or do you have to buy the windows version and run it with proton.
I got black Mesa on Linux from steam (works great), but is that a proton game? Last time I browsed Linux games on steam most seemed like they were indie with very few aaa titles..
No, games marked as Linux on the Steam store do not use Proton (by default) but are native (either ported or in some cases wrapped with Wine/whatever by the developer).
Black Mesa uses the Source engine for which Valve created their own ToGL wrapper but it's compile-time and much smaller than Wine.
Proton worked decently for VR last I tried 6 months ago. But I started it up again recently and everything is broken now, partially due to steam updates and partially due to updates to Unity. The entire reason I moved to Linux was because I loathe forced updates >:(
Same. I'm hoping that Valve's commitment to do a Linux-native release of Half-Life: Alyx is at least a commitment to get an end-to-end working VR experience on Linux sooner than later.
I only need a working VR videoplayer and a couple of experiences for demoing to people. Which 6 months ago was what was available and now nothing works, not even valves own VR tutorial
I believe natively supported games still receive the "Steamplay" icon, whereas proton-supported games will show the Windows icon, but will install and run on Linux. (assuming proton is configure)
The official whitelist lives here, https://steamdb.info/app/891390/info/ about halfway down in the "SteamPlay App Mappings" section. It has very stringent requirements and is not often updated. ProtonDB may be a better place to get an idea if a game is "playable," as opposed to the "perfect" that the whitelist is aiming for.
Last time I checked by default only a limited number of verified titles is playable with Proton, so if it appears in your list, it should work well.
You can enable Proton for all your games, although then I think there is no way to distinguish a verified title from the others.
I remember when proton was literally a pipe dream, and that was only only a few years ago. The improvement across linux drivers for GPUs as well as these technologies is great.
I would say that what is already available for linux is far better than what adobe has for image editing and video editing. Nuke and Houdini are much better for editing images than photoshop. Davinci Resolve is a much better video editor than premiere. Painting and vector illustrations are where Linux doesn't have good alternatives as far as I know. At this point there are multiple web based image editors that are far better than the low bar that Gimp sets. Gimp is a relic that most people would be better off forgetting about.
Krita is wonderful for painting and other applications like that. But isn't a full photoshop replacement. It is pretty heavily focused on digital painting.
Valve should ship the Steam Client native for ARM/Raspberry Pi Linux users.
It's a fairly large underserved community when it comes to gaming, and they're practically all Linux boxes, and the latest gens are perfectly capable of modern 3D gaming, if not all the AAA titles.
Fewer than there would be if Steam actually shipped ARM support to those who wanted it.
It's a classic chicken-egg problem.
I have a game on Steam, it builds and runs on ARM/RPi just fine, but there's no ARM in the list of architectures on Steamworks because the client doesn't support it. So I don't bother shipping the ARM build despite having one here and one of my artists using an RPi4 as their primary desktop with a functioning build of the game for testing.
We're talking about commercial interests here. If a game has been ported to native linux/SteamOS, it's likely just a recompile away from having ARM support. If the Steam client were made available to Pi users the demand would appear on the store for more ARM-compatible games and we'd all immediately jump on the opportunity for more sales from practically zero effort.
