Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
In the former, you can add any non-Steam game to launch under Steam, just give it a bash script that runs your game under Wine. Although Lutris is probably going to make that much easier to manage.
In the latter, I'd see if there's a custom Proton build you could install to Steam which would solve the specific issue(s). I mean... Proton is just Wine with some extra patches. No way for me to guess what you're getting stuck on, but Proton isn't all that far behind Wine-staging.
Hard to say more without more specifics on the real issue.
Most likely proton will also work if you try to disable DXVK and use WineD3D instead. Go to Steam > Library > right-click the game > Properties > set runtime parameters to:
If this works, it's a sign Vulkan isn't working (DXVK uses it while WineD3D uses OpenGL) and there may be ways to fix it... post back the result.
Or maybe you are running Steam Library from an NTFS partition? Proton has a harder time with this than Wine in some cases. See item [2.1] here:
https://steamcommunity.com/app/221410/discussions/0/1636417404917541481/
Finally, proton has some requirements, most but not all similar to WINE... maybe you should have a look:
https://github.com/ValveSoftware/Proton/wiki/Requirements
For more help, see items [6] and [7] on the first link, to know how to send us system info easily and proton debug logs.
you can install steam into your wine prefix, run it to open steam, install game. run game once to complete first run installation and activation. after that you can double click on game executable and it will open it with your default wine prefix. if it's DRM free it will just run, if it's steam DRM it will call your steam app in wine.
do you have any specific questions about managing such cases? I run my steam games from wine in most cases, some games are better that way indeed :)
Proton has small tweaks like windowed fullscreen by default to solve alt-tabbing issues, a framework for auto-setting-up per-game profiles to avoid configuration conflicts (as not everything works well for every game... and I'm not going to go into the merit if this works well or if there are better ways to pull it off, just that this is a thing that it does), and it integrates Steam features like achievement tracking and cloud saves syncing without needing a full-featured Steam for Windows instance running along the game inside Wine environment...
... and, more relevant to performance differences between Wine and Proton, it integrates stuff that is not made by Wine devs but by 3rd-parties, like DXVK as an alternative method for running DirectX over Vulkan, while off-the-shelf Wine does this via WineD3D which runs DX over OpenGL.
DXVK is a hot mess code, developed at an impressive speed to quickly plug a hole/gap in linux gaming, but very hard to maintain and improve over its current form without breaking something else (as more or less explained by the main dev himself). Yet for the games that it runs well it runs *very* well, a lot more so than WineD3D.
The next stage in Wine development involves, among a million announced things, implementing a new sort of WineD3D over Vulkan (can't remember if there is a specific name)... it will take a lot more time than DXVK and it may not achieve the same performance for every game/app out there, but it will focus on being more unified code, more accurate and reliable results, meaning even more games/apps will work over it... and the path trailed by DXVK will help them do it.
Aside from DXVK, Proton has been introducing some other game-oriented performance optimizations that may not be ideal for reliably running work apps but are great for games when they work. One worth of notice is esync, and later, to work around the limitations of esync (worthy of a systemd patch) Valve proposed fsync (worthy of a kernel patch which might benefit linux performance outside games, etc etc).
Another great 3rd-party solution implemented by default on Proton (while available but not default on Wine) was faudio (also available for manually adding to Wine for a while but IIRC now being merged as a permanent default solution? not sure about this bit)
Reading release notes, public announcements and changelogs for proton, dxvk, wine itself, makes it somewhat easy to see that these projects collaborate, that one complements the other and that eventually everyone wins regardless of who did what first, etc. It's not really a competition, and given the amount of upstreamed code contribuitions, it's also not just a marketing stunt or EEE on Valve's part, so I don't know what exactly you intended to imply with "promo leaflets" and "'benefits'", but there is a good chance you're being a bit unfair to their efforts by implying anything in the lines that Valve didn't bring anything to the table.
edit: there is quite a collection of links I could retrieve from past threads here, phoronix, GoL, Wine, DXVK and Proton repos but I'll allow myself to be lazy as it's already late in the night here ;)
edit2: the differences have been reducing over time, which is great news and proof of the upstreaming efforts being effective, plus the 3rd-party stuff is also easily integrated to Wine by the likes of Lutris, leaving only Steam-specific integration as a noticeable difference between proton and wine over some Lutris installs... also worth mentioning that while proton does bring new stuff to the table, it also lags behind a lot of improvements made in wine-staging and fresh versions of wine testing, due to Valve needing to periodically rebase it and reassess their tweaks over the new base, since it is a fork... meaning the bleeding-edge advances in Wine are also not always matched in proton... pros and cons for each game/gamer, and as usual we are spoilt for choice :)
I don't know, I don't want to sound negative or unfair to all efforts put into Proton, I just find it useless for my gaming. I'll explain it in detail in the 2d part of this post.
couple of days ago I spoke on gog forums about faudio where one user suggested to install faudio from external repo and then remove that repo. I explained that you don't have to remove that repo because it has only wine-staging and faudio and works for years (Debian 9, 10). So far Debian has no faudio in repos so if anyone needs wine-staging they have to add "OpenSuse repo" as per winehq FAQ. Debian Sid already has faudio so it won't be an issue soon. Debian also has no wine-staging so if user needs it - only external repos available (winehq or OpenSuse).
Why faudio is on Valve's achievement list? it was bundled with wine-staging for a year and any stable wine of version 5 or greater needs faudio. as long as Proton finally adopted 5.x it needs faudio as well. is it any better than previous xact? no, it is not. it was written for Valve to add it into Proton in place of DLLs they had no rights to redistribute. Wine can push corefonts, xact and any M$ stuff but Valve can't. Therefore faudio is just to make Valve and their DRM platform happy. it has no benefit for people who already uses wine.
You wrote very detailed list of things where Proton shines but it brings nothing new compared to wine. adding DXVK support is nice but it's one line to install and one short script to configure. windowed full-screen, per-application settings >> winecfg
esync >> one big broken mess, I wish they can keep it disabled by default
yes, this is not a competition because Valve just does what they need to secure their DRM platform with awful bloatware client. If you have wine and can run your games without steam chugging 2-4Gb of your RAM meantime, freezing in the background or popping hard coded notifications for garbage achievements that break your game resolution screen, you'll pick wine. I bet they need to have alt-tab mode because otherwise people will find themselves booted out of the game way too often.
You know what, maybe it is a bit negative. I'm angry with steam new UI and I can't force myself to run it. I do everything to avoid it, to the point where I use emulators or other means to run my games DRM free. I don't want to use Proton. for me it's uncalled feature (I have choice to use wine if it fails) while the most important feature I need - steam UI - has no replacement yet this is the worst piece of spyware I ever had to use. I can't force myself to use it. It's like forcing yourself to kiss a frog.
Though there still might be some corner cases where it makes sense, since Lutris does offer Proton installs along with Wine ones, I'd have a hard time knowing what good that would do.
Have you tried using the minimal launcher to avoid the new UI? I know how little it offers compared to the old native UI, but at least it lets you use Steam features in-game and launch the DRM-protected ones successfully.
yes, that's what I use for DRMed games, small list view in offline mode. it uses very little RAM (~700Mb which is acceptable) and does not leak, can play for hours without freezes. I'm not an achievement junkie so it's not a big deal to run offline client. But then I try to look into the future - this new UI not only suffers from bad performance (this can be fixed I hope) but it also drifts towards smartphone UI standards visually and uses intrusive telemetry inside of the library. as a Linux user I can't agree to telemetry in my own library.
Lutris offers protonified prefixes and GameHub (the tool I currently use to manage my games) also has Proton before default system wine (it takes it from steam folders I guess). yeah, it's getting popular to push Proton instead of wine.
since then, Valve made the Steam Deck, which helped push linux to a ton of people who never used it (and a big portion of them wouldn't have tried to use it otherwise)...
the "new" steam UI from back then is now being replaced by a newer UI made for the Steam Deck and rolled out a bit latter for steam in general
fsync is now merged to the linux kernel and even fsync2 exists... these can be used on all modern linux distros
the Steam Deck was only as well received as it was because Proton was there, seamlessly integrated with Steam, to help a huge portion of Steam's games catalogue be available for playing there despite most still being windows-exclusives
Valve made the "Steam Deck Verified" label, which eventually helped set gamers expectations on the Deck* about what works and what doesn't (either natively on linux or via Proton)
*= this also became a good guidance for working games on Linux in general, in addition to ProtonDB
The new label and the new device's success helped push a lot of devs into making a native linux version or fixing issues that broke their games under Proton (and that made them bad for playing with gamepads and smaller screens)
Some game devs gave up making linux native games because proton is enough, while a few others decided to make a native linux version to optimize their games better for the Deck
Game engines generally worked towards improving linux support, with Godot rising in prominence for indies (even more so now with Unity3D starting to implode under dumb management... shrug...)
Even some 3rd-party Anti-Cheat providers managed to get their things to work under linux or proton, sometimes making it as easy as a checkbox for a game dev to allow linux players into their anticheat-ridden games... but this is still far from an ideal situation in the competitive online multiplayer gaming scene... there is no dystopic kernel-level anticheat (sometimes seen as spyware, trojan, rootkit...) for Linux yet like there is for windows
Valve made ACO (a new vulkan shader compiler for AMD GPUs) and it is now available in Mesa and used by default in almost any modern linux distro... and it seriously reduced stutter and compile times for AMD GPUs
Win7 is dead (EOL) and Win10 is no longer "the last version of Windows that Microsoft will ever make"... it has a year of death hanging over its head now, and Win11 doesn't look kindly upon old hardware
Linux is firmly back above 1% and touched 2% (but now that's 1% or 2% of a much much much bigger total mount of Steam players)
...and so on and so forth
proton ge versions since 7.45 support uplay launcher
win 7 is a shame
afaik. you'll have to build your own version of wine to do that. Proton has some patches and stuff specfically for steam use, so you can't use your native wine directly like that. Proton also comes with some fixes and tweaks specifically for gaming that aren't included in standard wine. If you used plain native wine you'd also lose those.
https://github.com/Frogging-Family/wine-tkg-git
That one takes care of most of the hard work for you, and has a proton-tkg version you can use to build your own proton specifically for this.
It's a bit of a hassle though. Tried it a while ago, but the build dependencies were so numerous that I gave up as it wasn't worth the effort. If you're going to try this I recommend you create a VM installation of the same OS/version you have on your rig, and use the VM to build, because you'll have to install a lot of extra packages just for this that'll clutter the system. Better stuff it on a VM so it's an easy cleanup.
Apart from specific builds for very niche needs, the only advantage I can see to doing this is you'd get to compile wine optimized for your specific CPU (if you make that part of the compile setup). Might give slightly better performance in some cases.
and the benefit is another compatibility option.
if you played a lot of games with proton, you might notice some games work only with specific versions of proton, or have less glitches that with other versions of proton. if a game crashes with proton experimental, just switch to version 9, then 8, then 7, 6, 5, until it works, and there are high chances it will work with some version of it.
the same is with wine. i had at least three cases of games either working with only pure wine, or working better with it.
1. fallout new vegas with "new vegas reloaded" mod. with proton, proton-ge and wine-ge (in heroic game launcher) i had numerous graphic glitches.
but with system wine (in heroic launcher) it worked just fine.
2. quake 4. it just crashed with anything else but wine.
3. some game for unity, that had textures glitches with proton, but works flawlessly on wine.
maybe these cases could be fixed by fiddling with various dlls installing, or setting up some environment variables, but why would i spend potentially hours on that as long as quick try of different wine/proton versions just works