Proton is the Future of PC gaming. But how does it work? [Gardiner Bryant, YouTube]
Proton is the Future of PC gaming. But how does it work? [Gardiner Bryant, YouTube]
YouTube video: https://youtu.be/uScsmjvdwyo
Invidious video from YouTube without YouTube: https://inv.nadeko.net/watch?v=uScsmjvdwyo or https://invidious.nerdvpn.de/watch?v=uScsmjvdwyo
PeerTube, alternative video hosting platform based on Fediverse: https://subscribeto.me/w/isv3e2tfTJyGeAT6RRSR6M
Video description:
It’s clear there are some people who don’t understand Proton. So let’s talk about it. #Proton #SteamPlay #CompatibilityLayer
00:00 Introduction
00:41 The basics of a computer
01:46 What Proton is not
03:04 What is an emulator
04:32 Proton acts like a map
05:25 Proton translates API and system calls
06:18 Proton provides a Windows-like software environment
06:55 Why are some games incompatible?
08:52 Shouldn't we demand native Linux games?
11:07 Conclusion
YouTube face.... And useless red arrow?
Definitely No thanks
I was curious about how much you could actually read in the 11 minutes that this YouTube drivel wasted on getting a point across
I tested my reading speed and it was 346 wpm, so I'm guessing the average is about 300 because I read a lot
3300 words is an absolute fuckton of information.
I've no idea why anyone would waste 11 minutes listening to about two minutes worth of information
Not everyone can sit down and read for very long, some people want something to listen to while they do other things, some people learn better in audio format, and some people just like watching videos. It's fine if it is not your jam, but that is no reason to denigrate someone choosing to watch a video instead of reading an article.
In my experience, even when a game has a native Linux version, the Windows version run via Proton can often be the better choice.
In Tabletop Simulator, I wasn't able to join my friends' multiplayer sessions with the native Linux version. No problem with the Windows version via Proton.
The Linux version of Human Fall Flat isn't feature complete/outdated.
There are better examples though. Valheim runs fantastic aside from a bug that it picks the first instead of the default audio device for sound output on startup. It even supports mods and r2modman supports Linux as well.
Didn't have any problems with Spiritfarer either.
Yeah, it's unfortunately common to have games running better through proton than the native port. We've seen a lot of devs drop their linux port recently because the proton version ran better with fewer issues.
Obviously a well executed native linux port is preferable, but a lot of smaller devs have trouble justifying spending a lot of time working out kinks for a linux port if the game already runs great through proton.
Exactly, and I'd rather devs focus their time on making sure their Windows version works well via Proton than using that same time for a half-assed native Linux version.
I think a huge reason for this is how fragmented the linux ecosystem is.
A hundred ways to do simple things and even mundane things are suggested as "You can't do X with tool X easily. Just install package Y instead because it can also do it"
But now you have another program installed.
Also some parts of linux have much drama around it (https://www.phoronix.com/news/Bcachefs-Fixes-Two-Choices). This adds uncertainty.This is irrelevant with Steam though. Steam offers a runtime with preconfigured versions of everything that is needed to give the devs a consistent environment for their games to run no matter how fragmented the linux install base might be. This runtime is also what proton uses for ship its different versions.
It's because the devs just aren't testing their Linux build. If they at least had a steam deck and made sure it ran there, the community would figure everything else out on their own.
Hardware is not the only thing that can be emulated. Here's an example. To claim that things emulating software components are not emulators is simply incorrect, like claiming that squares are not rectangles. It's always disappointing to see someone spreading that falsehood.
It's true that Wine is not a hardware emulator, nor is Proton. But make no mistake: they are both emulators.
The unfortunate backronym made a kind of sense 20 years ago. At the time, lawsuits were flying hard and fast at projects offering APIs and tools modeled after commercial operating systems (Unix variants), and there was no established case law protecting them. The prospect of Wine contributors getting sued into oblivion by Microsoft was a very plausible threat. Rebranding it as "Wine Is Not an Emulator" helped frame it as something different as it grew and gained attention, and although that phrase is inaccurate, "Wine Is Not a Hardware Emulator" wouldn't have fit the existing name or distanced it from being seen as a Windows work-alike. Also, most emulators of the time happened to be hardware emulators, so it didn't seem like a terribly big stretch.
That time is gone, though. The legal standing for software based on reverse engineering is more clear than it was then. Microsoft has not sent its lawyers after our favorite runtime emulator. The backronym was thankfully abandoned by the project some years ago. Weirdly, there are still people on social media spreading false statements about what the word does and doesn't mean.
The term "Emulator" is not well defined and the boundaries are not always clear. But in computer hardware and software, emulation usually refers to CPU emulation. Overall one could argue that WINE is an emulation, because it emulates a certain "thing". But as said in computer science it has accepted by most people (for the sake of having categories) that CPU emulation is emulation, and otherwise its not. Especially if we talk in context of videogame emulation. Like Virtual Machines are no emulators, because they do not emulate the CPU itself.
Slightly offtopic: I often discuss and justify why I do not consider FPGA an emulator. Sure it emulates another hardware, but in the terms of console emulation of videogames, FPGA executes the CPU cycles native. There is no middle layer in between that needs to be interpreted, it runs the CPU commands that was "programmed into". So FPGA is mimicking, not emulating.
Just like with many other words in human language (which also is not clear across all translations and dialects of human language), the term "emulation" is just not 100% defined and there is nobody who has the definitive answer to it. And that's okay. It's a "domain specific" language; which means, you have to specify it before in order to make use. Otherwise you can assume it from context its "usual" meaning. Does not mean its clear, but it means nobody has the right to act like having a clear definition and saying anyone else is wrong.
as said in computer science it has accepted by most people (for the sake of having categories) that CPU emulation is emulation, and otherwise its not.
It's important to keep in mind that things said in computer science for the sake of having categories are usually said within the very narrow implicit context of a particular field of study, like microprocessor design. It makes sense there for the sake of brevity, just as arcane acronyms make sense when everyone in the room understands what they stand for in that context. But the context no longer applies when we're out in the rest of the world using a word that is not so narrowly defined, as we are now.
I think we mostly agree, because you pointed this out yourself:
It’s a “domain specific” language; which means, you have to specify it before in order to make use.
However, I want to clarify my position in response to this:
nobody has the right to act like having a clear definition and saying anyone else is wrong.
I often encounter people on social media chiding or mocking others for referring to Wine as an emulator, which is disheartening for a number of reasons. Importantly, the people reading such comments are being taught that it's wrong to call Wine an emulator, when in fact it is not wrong at all. Wine's very purpose is to emulate. This is plainly visible not just in how it is used, but also in how it is developed (many of its behaviors are reverse engineered Windows behaviors, departing from the API docs) and how it functions (it does a heck of a lot more than translating system calls).
The Wine project's FAQ acknowledges the misunderstanding, a bit indirectly, by pointing out that it is "more than just an emulator".
Unfortunately, since most people in the discussions I mentioned have no visibility into Wine's internals, they don't know any better than to accept what they were told by multiple people on the internet. They are misled by a smug few who love to tell others they're wrong by repeating that officially abandoned slogan that was never really true (at least not in the context that framed it) in the first place. And then some of the misled people adopt it themselves, so we end up with more of the "you're wrong" attitude, perpetuation of a ridiculously narrow understanding of the word, and people who publish about the topic performing awkward linguistic gymnastics to avoid simply saying "emulator" for fear of rebuke.
I think all three of those results make the world a little worse, so I'm here to let everyone reading know that it's perfectly appropriate to call Wine (or Proton) an emulator. Anyone who claims it's wrong to do so is perhaps a hardware field specialist who has lost sight of the importance of context in language, or (more likely) either honestly mistaken or an internet troll.
If games go linux native, how long until Microsoft gets wsl working for games?
You mean to play Linux games through WSL? Well, Microsoft doesn't have any reason to, as all games are available for Windows. Or do you suggest the Frankenstein's Gaming playing Linux games with Proton through WSL on Windows? That would be truly marvelous. xD
There’s really nothing preventing that now. Used to be you just forwarded X (mobaXterm is great); looks like there’s an MS offering now.
As for Linux-exclusive games, there are some (eg this publisher) but really only because no one has bothered to make a Windows port. tbh you could probably get them running on macOS without much trouble because the toolchain’s all the same.
I wish he wouldn't repeat the idea that Proton is acceptable to game devs and Linux users shouldn't demand native games. I'm much closer to Nick's (from Linux Experiment) idea: That these games work as long as a company like Valve pays for Proton. The day Valve stops is the day these Proton games start to rot. For archival, for our own history, and for actual games on Linux, we should want Linux native games.
The thing is, the "no tux no bucks" crowd doesn't advocate for other people to say the same. The proton crowd is actively telling the "no tux no bucks" people to shut up, and it's not very nice. We need a multitude of views to succeed in the long term as a community.
I maintain that Proton could be a gateway to open the Linux market and create a sufficient share of revenue that, if and when it is shutdown, it's lucrative enough to make natively compatible games.
It's a bit of a deadlock issue: Most Devs will only develop for Linux if they see there's money to be made there and they can estimate it will be worth the effort. But we need games on Linux for that to happen.
Proton is a stop-gap solution to provide the latter and lower the barrier on both ends: I can play games on Linux and devs have an easier time shipping their games to a Linux audience. I hope long term, the major frameworks will feature defaults that allow devs to easily do so without relying on Steam, but until then, Proton is better than nothing.
This is fine. I don't mind a diversity of opinion here. I agree that Proton is a stop-gap solution, and that most older games are going to need it, and newer AAA games are not going to support Linux all of a sudden.
However, I do think that we should continue to encourage developers to create native builds when they can. Indie devs tend to do this and it's a pretty great experience. Not only that, it often enables playing on unusual devices such as SBCs. For example, UFO 50 was made in Gamemaker, which offers native Linux builds, and it's already on Portmaster. You basically can't do that with Proton.
My problem is calling people who want Linux native games misguided or wrong. I really don't think that's helpful.
I recognize the importance of Proton to bridge the gap and bring users over who would never switch if they can't play all their Windows games.
But I won't ever agree that Proton should just replace proper native support.
Thanks, I'll add that link to the post content.
Another thing that wasn't mentioned in the video that Proton does is it also -- sometimes, depending on the game -- checks a list of known requirements for a game and installs them through winetricks, or makes other recommended changes to game files that are known to make the game work.
When Proton is updated and the patch notes mention that a game was fixed, it's something to do with this part of the process. A certain library, or whatever was missing and Proton installs it for you behind the scenes.
It also runs WINE through Steam's launcher (aka Steam Linux Runtime) which has some common redistributables (aka Steamworks SDK Redist) built right into it, and it also runs appropriate anti-cheat solutions (aka Proton EasyAntiCheat Runtime or Proton BattlEye Runtime).
I actually didn't know the Steam Linux Runtime was WINE. Nice. (Note, I'm not the author of the video.)
It is not just WINE. The Steam Linux Runtime is a stack of linux native libraries, binaries and tools designed to give game devs a consistent version of things to develop games against. Recently they moved this to be container based and I believe proton (which contains wine) is run inside this runtime as well.