Valve Breaks the Shackles of Proton(boilingsteam.com)
boilingsteam.com
Valve Breaks the Shackles of Proton
https://boilingsteam.com/valve-breaks-the-shackles-of-proton/
178 comments
Hi, I'm involved in this project. If anyone here is a skilled C programmer interested in getting paid to improve Wine and Proton, please throw me an email (see profile or use your detective skills to find my work email).
Just wanted to say before I picked up my Windows desktop I tried out CrossOver to play a few games on my MBP. Worked brilliantly.
Wish my C chops were better! Anyway, nice work. Envious of the wood shop.
Wish my C chops were better! Anyway, nice work. Envious of the wood shop.
Interesting, is CodeWeavers employed/contracted/collaborating with Valve?
Yep! I worked at CodeWeavers during Proton development and we were basically contracted by Valve to build the whole thing for them. Although if projects like that interest you, the work on supporting Wine on MacOS after they drop 32 bit application support is amazing!
> supporting Wine on MacOS after they drop 32 bit application support
Steam itself still looks be 32-bit on macOS:
Steam itself still looks be 32-bit on macOS:
lipo -info /Applications/Steam.app/Contents/MacOS/steam_osx
Non-fat file: /Applications/Steam.app/Contents/MacOS/steam_osx is architecture: i386The executable in /Applications is 32-bit, but it's just a launcher for the real Steam app in ~/Library/Application Support/Steam/Steam.AppBundle which is 64-bit.
Ahh thank you! I knew I was missing something... I'd get the alert message, then the Steam app would seemingly close and re-launch. I wonder why it is architected like that.
I guess that it's like that in order to be able to update the executable for non-privileged users (who can't write to /Applications), which could be e.g. kids' user accounts in the family computer.
Love you guys for doing this, keep it up!
Looking forward to the eventual release of Proton for MacOS through DXVK, MoltenVK, etc.
I wrote on keybase
v_lisivka(5)
Quick question if you don't mind - what do the valve guys think of Windows Subsystem for Linux ? It's tempting even for me (who has used only Linux for 20 years now).
https://www.phoronix.com/scan.php?page=article&item=wlinux-w...
In most tests, WLinux and WLinux Enterprise simply performed inline with the other Linux distributions benchmarked.
Performance is pretty much at par (and in some cases better than Linux).
Do you guys envision a long term disruption in this space ?
https://www.phoronix.com/scan.php?page=article&item=wlinux-w...
In most tests, WLinux and WLinux Enterprise simply performed inline with the other Linux distributions benchmarked.
Performance is pretty much at par (and in some cases better than Linux).
Do you guys envision a long term disruption in this space ?
Filesystem performance is closer to windows than linux which can be a deal-killer. Probably not for games.
> Filesystem performance is closer to windows than linux
Well.. filesystem performance is just bad under WSL period. Much worse than native NTFS or ext4 on the same hardware. It's so far from both that saying it's closer to one or the other doesn't _really_ make sense.
Well.. filesystem performance is just bad under WSL period. Much worse than native NTFS or ext4 on the same hardware. It's so far from both that saying it's closer to one or the other doesn't _really_ make sense.
I imagine the stance is that Linux is meant to be a backup plan to Microsoft closing things down. WSL keeps you locked in with Microsoft.
It has the benefits of easing someone into Linux so they can migrate to Linux full time.
But it doesn't resolve any of the same problems as "Why support Linux gaming in general?" Because the biggest one is the whole Microsoft thing.
It has the benefits of easing someone into Linux so they can migrate to Linux full time.
But it doesn't resolve any of the same problems as "Why support Linux gaming in general?" Because the biggest one is the whole Microsoft thing.
Is this really a threat? Because I haven't seen a shred of evidence to believe that Windows is going to block Steam. Hell they are actually releasing Xbox games on Steam!
But I guess Valve is flush with cash to throw at their hobby projects.
But I guess Valve is flush with cash to throw at their hobby projects.
It was a big threat on Windows on ARM which only allowed you to install applications from the windows store or use an extremely slow x86 emulation layer. Microsoft blocked any browser from the windows store that was not based on the edge engine so Edge was the only usable browser available on ARM because emulated browsers simply cannot compete. Of course in the end it never went anywhere and even Edge's engine is about to be replaced with Chromium.
Nowadays Windows on ARM is basically the second coming of Windows RT, a massive failure. The biggest difference is that this time they decided to not produce a million devices too many.
Nowadays Windows on ARM is basically the second coming of Windows RT, a massive failure. The biggest difference is that this time they decided to not produce a million devices too many.
Perhaps it's not going to block Steam because they have an escape path. They were leaning heavily into UWP right around the time Steam for Linux became a big thing.
I look forward to my Steam friends being notified I'm playing Office Professional 2019.
I've been very impressed with what I've used so far. Most recently I've had an unofficially supported game (Skyrim) successfully query my hardware and accurately set the graphics settings.
I've been very impressed with what I've used so far. Most recently I've had an unofficially supported game (Skyrim) successfully query my hardware and accurately set the graphics settings.
Same here. Skyrim already runs perfectly for quite a while, and now the ability to circumvent native clients changes a lot again.
In my case there's a game where the Linux version always crashes after about 30 minutes, and I hope it'll run smooth enough with Proton.
In my case there's a game where the Linux version always crashes after about 30 minutes, and I hope it'll run smooth enough with Proton.
Damn. I can't even get the game to run right in Windows. It's got that physics glitch where it can't make it past the gate in the intro.
There are several mods that address this issue (last but not least LAL).
LAL?
I feel like the last time I tried to fix this I discovered the mod to fix it was only for the 'Special Edition' or something which I didn't have.
I feel like the last time I tried to fix this I discovered the mod to fix it was only for the 'Special Edition' or something which I didn't have.
I use Discord for communicating with some friends and coworkers and specifically set it up so it's only aware of one very old text adventure and will only tell people if I'm playing that.
Skyrim has worked via wine pretty much since it was released, as you can confirm on Wine AppDb here: https://appdb.winehq.org/objectManager.php?bShowAll=true&bIs...
Makes sense, considering how long the game engine’s been around.
Crossover office has been the key product for helping with that.
For people who don't know what Proton is:
https://github.com/ValveSoftware/Proton
> Compatibility tool for Steam Play based on Wine and additional components
> 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.
> Most users will prefer to use Proton provided by the Steam client itself. The source code is provided to enable advanced users the ability to alter Proton. For example, some users may wish to use a different version of Wine with a particular title.
> Compatibility tool for Steam Play based on Wine and additional components
> 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.
> Most users will prefer to use Proton provided by the Steam client itself. The source code is provided to enable advanced users the ability to alter Proton. For example, some users may wish to use a different version of Wine with a particular title.
I thought it was a physics discovery u_u
Linux user here. Great news overall, but I do have some concerns:
1) The changes seem to be designed to help shoddy Linux ports--e.g. those that haven't been updated in awhile or that have very poor performance. I worry that developers will see this as an alternative to native Linux ports, and instead of getting awesome games that work on Linux without WINE (see: Beamdog's awesome Enhanced Editions of classic Interplay/Bioware/Black Isle RPGs), we'll simply see all Linux games running in WINE containers. WINE is great, but it's not perfect. When Proton was first enabled, I tried running System Shock Enhanced Edition and it crashes immediately. System Shock Classic, on the other hand, is certified for OSX and Linux and runs properly (although for all I know SSC might just be a tweaked WINE container).
2) Not all games work with WINE. That's why there's the WINE compatibility list, along with community forums dedicated to making tweaks to get the games running. I fear that throwing everything at WINE effectively puts the onus of getting the game working onto the WINE community, rather than the game's developers. I suppose in Best Case scenario (after native Linux builds, of course), game developers could contract out the CrossWeavers guys to help get their specific game working within WINE and that might still be cheaper than the resources required to build the game natively. But whether they'll actually do that remains to be seen.
1) The changes seem to be designed to help shoddy Linux ports--e.g. those that haven't been updated in awhile or that have very poor performance. I worry that developers will see this as an alternative to native Linux ports, and instead of getting awesome games that work on Linux without WINE (see: Beamdog's awesome Enhanced Editions of classic Interplay/Bioware/Black Isle RPGs), we'll simply see all Linux games running in WINE containers. WINE is great, but it's not perfect. When Proton was first enabled, I tried running System Shock Enhanced Edition and it crashes immediately. System Shock Classic, on the other hand, is certified for OSX and Linux and runs properly (although for all I know SSC might just be a tweaked WINE container).
2) Not all games work with WINE. That's why there's the WINE compatibility list, along with community forums dedicated to making tweaks to get the games running. I fear that throwing everything at WINE effectively puts the onus of getting the game working onto the WINE community, rather than the game's developers. I suppose in Best Case scenario (after native Linux builds, of course), game developers could contract out the CrossWeavers guys to help get their specific game working within WINE and that might still be cheaper than the resources required to build the game natively. But whether they'll actually do that remains to be seen.
IMO as someone who works on games, developers will come along with high quality Linux builds when there are a significant number of users that demand it. I think anyone who's doing a Linux port now is doing it out of the goodness of their hearts and not as an economic decision. It doesn't matter if you're using an engine that already supports Linux, it's still extra work to develop and test, and it's still more support issues that (in the current market) you are very unlikely to make back in additional sales. I'm certain most Linux gamers also have Windows installs, so while they might complain about having to dual-boot, they still do it.
If Proton bridges the gap to the point where people are 1) more willing to be on Linux and 2) less willing to deal with dual-booting for the few games that don't work without it, then maybe the number of Linux-exclusive gamers will grow. That's when you'd see significant attention paid to proper Linux builds. (There are of course other impediments to people switching over to Linux full-time besides games support, so I don't think the Year of Desktop Linux is quite imminent yet.)
If Proton bridges the gap to the point where people are 1) more willing to be on Linux and 2) less willing to deal with dual-booting for the few games that don't work without it, then maybe the number of Linux-exclusive gamers will grow. That's when you'd see significant attention paid to proper Linux builds. (There are of course other impediments to people switching over to Linux full-time besides games support, so I don't think the Year of Desktop Linux is quite imminent yet.)
> think anyone who's doing a Linux port now is doing it out of the goodness of their hearts and not as an economic decision.
I do think there is more overlap between those who buy the game to play on Windows, and those who would be willing to at least give it a try on Linux. All the stats I see seem to treat them as a disjointed set of users.
I do think there is more overlap between those who buy the game to play on Windows, and those who would be willing to at least give it a try on Linux. All the stats I see seem to treat them as a disjointed set of users.
I gave several early gen i7 new life with SteamOS. More or less sets up nicely and could play a surprising number games in my library. One of the problems with giving away boxes to family/friends is the OS was worth more than the hardware and this really helps. The normal Linux desktop was a bit harder to get up and running (xterm, of all things, does not work by default) but with a browser and my normal dev tools all more or less work once you get the repos set up.
I think this is an alternative to native Linux ports, one that makes good financial sense to developers, and happens to set a very clear and simple target - Does my game run well in Proton?
That's reasonably easy to test, which is very important.
I have zero problems with this as an approach - but I always favor pragmatism over purism.
I want my games to work on my linux box so I can ditch the win10 partition, whether they do that through a native port, WINE, Proton, or some satanic ritual... I don't really care.
If Proton is better than most shoddy ports, makes financial sense for devs, and unlocks games for me... Who gives a flying fuck if no one is making native linux builds?
That's reasonably easy to test, which is very important.
I have zero problems with this as an approach - but I always favor pragmatism over purism.
I want my games to work on my linux box so I can ditch the win10 partition, whether they do that through a native port, WINE, Proton, or some satanic ritual... I don't really care.
If Proton is better than most shoddy ports, makes financial sense for devs, and unlocks games for me... Who gives a flying fuck if no one is making native linux builds?
The lesson of the last 5 years (!) of Steam on Linux is that not all native games work with Linux. MOST of the high profile (aaa budget) ports are shoddy. Virtually none of them run with equivalent Windows performance (let alone better performance as Valve initially claimed). Proton is the best hope for AAA Linux gaming for the foreseeable future.
Those are legitimate concerns however the reality is that platform support is dictated by demand and Linux is a distant 8th behind PS4, Xbox 1, Switch, iOS, Android, PC, and Mac.
We've already seen users shift from Windows to Mac, iOS and Android. It's unclear how the landscape might change in the future so rather than encouraging developers to split their efforts between a myriad of platforms or API, maybe we establish an abstracted platform that they target and then each respective platform can support that?
Obviously Microsoft, Sony, and Nintendo aren't going to get behind that but since the Xbox already shares an API layer with Windows 10, and Microsoft is committed to maintaining compatibility longer, then perhaps that's the target going forward?
We've already seen users shift from Windows to Mac, iOS and Android. It's unclear how the landscape might change in the future so rather than encouraging developers to split their efforts between a myriad of platforms or API, maybe we establish an abstracted platform that they target and then each respective platform can support that?
Obviously Microsoft, Sony, and Nintendo aren't going to get behind that but since the Xbox already shares an API layer with Windows 10, and Microsoft is committed to maintaining compatibility longer, then perhaps that's the target going forward?
> maybe we establish an abstracted platform that they target and then each respective platform can support that?
There is active and intentional hostility by many platforms to avoid this happening. Making cross platform development harder makes sense if you want to hold developers hostage in your environment and make the effort to work anywhere else a substantial investment.
Apple, Microsoft, Sony, and Nintendo all do this. It was really a sea change for Nintendo to support Vulkan on the Switch. Sony said they would, but never did. Microsoft adamantly uses DX as a lock in tool for the Xbox. Apple made Metal to make cross compatibility between iOS and anything else a huge pain.
At least for games, right now, you cannot do anything but write custom handler code for the Xbox and PlayStation. SDL doesn't support them, their devkits are proprietary, and the Switch is only better because Icculus ported SDL to it. You want to use Vulkan because it has the most API surface, but it only works everywhere but Xbox because there is no Vulkan -> DX wrapper.
So if you want a write once run everywhere game the best combo is SDL + Vulkan working on Windows, Android, and Linux natively. On iOS and OSX with MoltenVK wrapping the Vulkan. On Switch by PMing Ryan Gordon for the secret Switch SDL. But never on Xbox or PS4 in any form, there is no way to be compatible with them.
Which is probably why DirectX is still so entrenched. UWP + DX11 means Windows (7+) and Xbox support, DX12 means Windows 10 and Xbox One support. DX11 is now also starting to mean Linux and maybe even OSX support. That covers more of the market than SDL and Vulkan does despite it all being proprietary and Microsoft only because... thats where about half the market is by itself.
That all being said most of this is moot. Almost no modern game is being made in isolation. Everything is using Unreal 4 or Unity (or hopefully even Godot). All of those are available to varying degrees of completeness everywhere. You don't write your shaders in HLSL, you write them in your engine wrapper shader language. Once your game is done you then chose to press the deploy button to whatever systems you want. But then it turns out these humongous code monsters called game engines end up having a lot of esoteric bugs and breakages across platforms that drive developers not to support anything but high volume targets - ie, the consoles and Windows, maybe Android and iOS.
There is active and intentional hostility by many platforms to avoid this happening. Making cross platform development harder makes sense if you want to hold developers hostage in your environment and make the effort to work anywhere else a substantial investment.
Apple, Microsoft, Sony, and Nintendo all do this. It was really a sea change for Nintendo to support Vulkan on the Switch. Sony said they would, but never did. Microsoft adamantly uses DX as a lock in tool for the Xbox. Apple made Metal to make cross compatibility between iOS and anything else a huge pain.
At least for games, right now, you cannot do anything but write custom handler code for the Xbox and PlayStation. SDL doesn't support them, their devkits are proprietary, and the Switch is only better because Icculus ported SDL to it. You want to use Vulkan because it has the most API surface, but it only works everywhere but Xbox because there is no Vulkan -> DX wrapper.
So if you want a write once run everywhere game the best combo is SDL + Vulkan working on Windows, Android, and Linux natively. On iOS and OSX with MoltenVK wrapping the Vulkan. On Switch by PMing Ryan Gordon for the secret Switch SDL. But never on Xbox or PS4 in any form, there is no way to be compatible with them.
Which is probably why DirectX is still so entrenched. UWP + DX11 means Windows (7+) and Xbox support, DX12 means Windows 10 and Xbox One support. DX11 is now also starting to mean Linux and maybe even OSX support. That covers more of the market than SDL and Vulkan does despite it all being proprietary and Microsoft only because... thats where about half the market is by itself.
That all being said most of this is moot. Almost no modern game is being made in isolation. Everything is using Unreal 4 or Unity (or hopefully even Godot). All of those are available to varying degrees of completeness everywhere. You don't write your shaders in HLSL, you write them in your engine wrapper shader language. Once your game is done you then chose to press the deploy button to whatever systems you want. But then it turns out these humongous code monsters called game engines end up having a lot of esoteric bugs and breakages across platforms that drive developers not to support anything but high volume targets - ie, the consoles and Windows, maybe Android and iOS.
Thing is, go to any GDC, IGDA or IGF event and you will rarely get developers talking about feeling hostage of the platforms.
Most will happily discuss about issues with publishers, game design ideas, making a successful game and how to take advantage of the IP to branch into other areas like movies or toys, and taking advantage of the hardware to the max in some cool ways, demoscene style, how to get that exclusivity deal offer from publishers.
Even Vulkan on the Switch feels like testing waters, as Sony did with GL ES 1.0 + Cg on the PS 2, as the main 3D API is NVN.
It is quite easier to check this by going through the talks available publicly on the GDC Vault.
Most will happily discuss about issues with publishers, game design ideas, making a successful game and how to take advantage of the IP to branch into other areas like movies or toys, and taking advantage of the hardware to the max in some cool ways, demoscene style, how to get that exclusivity deal offer from publishers.
Even Vulkan on the Switch feels like testing waters, as Sony did with GL ES 1.0 + Cg on the PS 2, as the main 3D API is NVN.
It is quite easier to check this by going through the talks available publicly on the GDC Vault.
> We've already seen users shift from Windows to Mac, iOS and Android
Not really. Mobile games are a new segment, not really a replacement.
Mac has little appeal to gamers. They could, they don't care. It's better to be neat looking.
Not really. Mobile games are a new segment, not really a replacement.
Mac has little appeal to gamers. They could, they don't care. It's better to be neat looking.
> maybe we establish an abstracted platform that they target and then each respective platform can support that?
WebAssembly is this, basically.
WebAssembly is this, basically.
I eagerly await the day when all my games are electron apps that break because they can't load an old version of libnode.
The best thing about wasm is that it's not JavaScript. ~
WebAssembly and Electron are different things. If games were delivered over the web in WebAssembly, not being able to load an old version should not be a problem - the web is largeyl forwards-compatible, and browser vendors take care to Not Break The Web.
Ok kiddies, gather 'round and let grandpa tell you a story of literally every other VM that was pushed as the final solution to all our cross platform woes.
Here's a spoiler: we still write native applications.
Here's a spoiler: we still write native applications.
Actually, I have those same concerns. Nevertheless, I have to admit that Valve made a lot more games easily playable than Feral over the last years. Don't get me wrong. I own quite a few Feral ported games and love the quality they deliver. But I also saw a lot of devs talking about how much work it would be to support another platform (even if it could be done in 2 hours as some others have demonstrated (comparing same engines and technical complexity here)), and therefore not caring about Linux and MacOS.
So I am very grateful for the results we see from Valve. Ultimately, we might see fewer native Linux ports on the one hand, but on the other hand, we might see more people using Linux as gaming is becoming a lot easier now.
So I am very grateful for the results we see from Valve. Ultimately, we might see fewer native Linux ports on the one hand, but on the other hand, we might see more people using Linux as gaming is becoming a lot easier now.
As long as the developer/publisher offers the same level of support as they do for Windows users, and as long as performance/quality are comparable with running on Windows, I really couldn't care less whether a game was "natively" ported or is running under Proton or a Wine-based wrapper. At that point it's just an implementation detail, no different from a developer choosing .NET or Java or what have you to achieve cross-platform support.
Although there may be a positive aspect to this. Valve mentions that developers that choose Vulkan over D3D will have a better chance to work on Linux through the compatibility layer. As far as I know, making your product for Vulkan makes you halfway to a full Linux port.
Honestly, if WINE containers offer around 85-90% performance of Windows Native, I'm totally down.
And that's currently the case. I have been playing a little bit of No Man's Sky these days on WINE. Amazing game, I'm always at 60fps too.
And that's currently the case. I have been playing a little bit of No Man's Sky these days on WINE. Amazing game, I'm always at 60fps too.
don't know why but most port are really suffering from more than just the effort that's put behind them; even native and up to date port used to work better using wine, and that's even for games that don't touch the graphic card. for example dwarf fortress on linux runs so much faster in wine.
> I worry that developers will see this as an alternative to native Linux ports
You should worry that developers will not see this as an alternative to native Linux ports. Ongoing support for Linux just isn't worth it, it has been proven time and time again. If developers instead focused on Proton/WINE as a platform they might get some real value with only minor effort.
The problem with Linux users is that they're the armchair developers in every comments section, complaining that some port is bad because it's "not native" or not 100% as good as the Windows version. You just have to ignore that.
You should worry that developers will not see this as an alternative to native Linux ports. Ongoing support for Linux just isn't worth it, it has been proven time and time again. If developers instead focused on Proton/WINE as a platform they might get some real value with only minor effort.
The problem with Linux users is that they're the armchair developers in every comments section, complaining that some port is bad because it's "not native" or not 100% as good as the Windows version. You just have to ignore that.
It is amazing how far linux gaming has come in a few years. It's true that in tech "a few years" is an eternity, but "linux graphics drivers" have always been an exception to that rule...
In negotiating theory there's an idea called 'BATNA' [1] which says:
1. If A is negotiating with B, but they have an alternative option which is C, then A will never accept B giving them a worse deal than C; and B will know that, and realise they have to do better than C.
2. For this reason, if A wants a better deal from B, they have to improve on C - and that's true even if they don't plan to rely on C.
For example, an employee (A) who wants to be paid more by their current employer (B) might interview with another company (C) and use the offer from C to negotiate a higher salary from B.
Likewise, Valve fears that Microsoft will eat their cake. MS could lock down their platform, and force all software sales through a store where they take a 30% cut, just like iOS and Android do already.
Investing in Linux gaming is Valve's BATNA: If Microsoft makes Windows worse for Valve than steam boxes are, Valve can start pushing steam boxes hard; and the better steam boxes are, the more effective and credible this alternative is, and hence the more leverage Valve has over MS.
[1] https://en.wikipedia.org/wiki/Best_alternative_to_a_negotiat...
1. If A is negotiating with B, but they have an alternative option which is C, then A will never accept B giving them a worse deal than C; and B will know that, and realise they have to do better than C.
2. For this reason, if A wants a better deal from B, they have to improve on C - and that's true even if they don't plan to rely on C.
For example, an employee (A) who wants to be paid more by their current employer (B) might interview with another company (C) and use the offer from C to negotiate a higher salary from B.
Likewise, Valve fears that Microsoft will eat their cake. MS could lock down their platform, and force all software sales through a store where they take a 30% cut, just like iOS and Android do already.
Investing in Linux gaming is Valve's BATNA: If Microsoft makes Windows worse for Valve than steam boxes are, Valve can start pushing steam boxes hard; and the better steam boxes are, the more effective and credible this alternative is, and hence the more leverage Valve has over MS.
[1] https://en.wikipedia.org/wiki/Best_alternative_to_a_negotiat...
More importantly Valve faces competitions from a lot of other game stores lately. They still have the first mover advantage but who know what happens in the next 5 years with Fornite and the like. They need to own something else than an online store to build their future.
[deleted]
> Likewise, Valve fears that Microsoft will eat their cake. MS could lock down their platform, and force all software sales through a store where they take a 30% cut, just like iOS and Android do already.
This isn't theoretical, right? It was stated upfront as a plan for Windows 10 and it inspired Valve to invest in Linux/SteamOS/Steam Box ecosystem.
This isn't theoretical, right? It was stated upfront as a plan for Windows 10 and it inspired Valve to invest in Linux/SteamOS/Steam Box ecosystem.
It was Windows 8 at the time, but yes.
[0] https://www.bbc.co.uk/news/technology-18996377
[0] https://www.bbc.co.uk/news/technology-18996377
There are (were?) specific versions of windows that only allow software to be installed from the Microsoft store. Generally, the come on really low-end cheap laptops, with the note that it's for improved security (and I'm sure there's a discount on the cost of Windows, which is what makes it attractive to manufacturers).
Refer to Windows 10 S/Windows 10 S mode[0].
[0] https://en.wikipedia.org/wiki/Windows_10_editions#Discontinu...
[0] https://en.wikipedia.org/wiki/Windows_10_editions#Discontinu...
> Investing in Linux gaming is Valve's BATNA: If Microsoft makes Windows worse for Valve than steam boxes are, Valve can start pushing steam boxes hard; and the better steam boxes are, the more effective and credible this alternative is, and hence the more leverage Valve has over MS.
The other option would be to put some pressure onto Apple to get their stuff in order - and finally release new desktop Macs that are upgradeable as well as allow NV/AMD to release their own GPU drivers.
The other option would be to put some pressure onto Apple to get their stuff in order - and finally release new desktop Macs that are upgradeable as well as allow NV/AMD to release their own GPU drivers.
Apple is probably even more likely to lock their users down to using their app store only and taking a 30% cut is than Microsoft is. That's an "out of the frying pan into the fire" solution.
With Linux, Valve has the control. If they were getting really serious with this, I'd expect them to take full control over the hardware they're selling too, but for the moment, this is still a pretty solid BATNA-threat for them.
With Linux, Valve has the control. If they were getting really serious with this, I'd expect them to take full control over the hardware they're selling too, but for the moment, this is still a pretty solid BATNA-threat for them.
Apple will never offer a desktop computer with specs that gamers will accept at a price point that will sell at the volumes that Valve wants/needs
This, and Apple has shown over and over they absolutely don't care about gamers. It would be very surprising this changes anytime soon.
"This, and Apple has shown over and over they absolutely don't care about gamers."
Not true. They advertize games very vocally in iOS AppStore. I know that's not what you meant, but in the largest context a "gamer" is not an enthusiast, but just a person who likes to play a game now and then.
Not true. They advertize games very vocally in iOS AppStore. I know that's not what you meant, but in the largest context a "gamer" is not an enthusiast, but just a person who likes to play a game now and then.
> but in the largest context a "gamer" is not an enthusiast
In the context of Valve customers potentially willing to install Linux however, it's pretty clear what is meant.
In the context of Valve customers potentially willing to install Linux however, it's pretty clear what is meant.
> This, and Apple has shown over and over they absolutely don't care about gamers.
Yet gamers have similar demands (in terms of performance) to the core demographic of Apple users pre-iPhone: professionals in the 3D/animation/audio creative scene. The question is, will Apple ever think about this market again or concede victory to Windows? They haven't shown much progress the last few years, but on the other hand if there's one group which is willing to shell astronomic sums on highest end Apple equipment it's creatives.
Yet gamers have similar demands (in terms of performance) to the core demographic of Apple users pre-iPhone: professionals in the 3D/animation/audio creative scene. The question is, will Apple ever think about this market again or concede victory to Windows? They haven't shown much progress the last few years, but on the other hand if there's one group which is willing to shell astronomic sums on highest end Apple equipment it's creatives.
It's a shame really, because in the past their products were actually quite popular for games, because they were also popular for game developers who were often serious personal computing enthusiasts at the time. And Bungie was a really good developer that was Mac-first right up unitl they were acquired by MS.
Now that Bungie is independent again, maybe the post-Jobs Apple could finally come to embrace gaming? Throwing thousands of dollars at completely overbuilt gaming rigs and their associated cosmetics is pretty common, you think they'd be an attractive mark for a lifestyle-brand company like Apple.
Now that Bungie is independent again, maybe the post-Jobs Apple could finally come to embrace gaming? Throwing thousands of dollars at completely overbuilt gaming rigs and their associated cosmetics is pretty common, you think they'd be an attractive mark for a lifestyle-brand company like Apple.
How common do you really think it is? And why would "gaming" be the lifestyle Apple wants to be associated with?
> How common do you really think it is?
Look at the sales of LED RAM.
I think Apple might want a piece of a market that's willing to overspend. They don't have to buy in to the aesthetic and culture of current "hardcore gamers", they can provide an alternative style and culture that expresses different values, like sophistication and creativity. I'm sure a lot of people would like an alternative to the Red Bull'd-up pseudo-hacker look.
Look at the sales of LED RAM.
I think Apple might want a piece of a market that's willing to overspend. They don't have to buy in to the aesthetic and culture of current "hardcore gamers", they can provide an alternative style and culture that expresses different values, like sophistication and creativity. I'm sure a lot of people would like an alternative to the Red Bull'd-up pseudo-hacker look.
Should I look at the sales of LED RAM and compare them to total game sales? I doubt that will demonstrate what you're claiming. A raw number means nothing.
> I'm sure a lot of people would like an alternative to the Red Bull'd-up pseudo-hacker look.
Are those people buying LED RAM even though it's not what they really want?
> I'm sure a lot of people would like an alternative to the Red Bull'd-up pseudo-hacker look.
Are those people buying LED RAM even though it's not what they really want?
Apple are basically not amenable to pressure - Valve have no leverage on them at all, really, since they're a mobile device company with eight hundred billion dollars who occasionally release laptops for the niches of musicians and designers.
I think Second last paragraph would have been enough. The rest is superfluous
The new feature to use proton with arbitrary executables is a godsend. No more struggling with wine prefixes, we can let Steam handle it.
I intend to use it with ebook DRM crackers, mod managers for Beat Saber and ESO, maybe even non-Steam VR titles, like the Vive store. Maybe some of the crappy desktop clients for enterprise webapps that I need for work too.
I intend to use it with ebook DRM crackers, mod managers for Beat Saber and ESO, maybe even non-Steam VR titles, like the Vive store. Maybe some of the crappy desktop clients for enterprise webapps that I need for work too.
> ebook DRM crackers
please don't, not through steam. i'm sure steam collects some statistics on how people are using proton, and if they start seeing stuff like this show up they might start locking it down again.
you might be able to run proton stand-alone for stuff like this if you really want to. https://github.com/ValveSoftware/Proton
please don't, not through steam. i'm sure steam collects some statistics on how people are using proton, and if they start seeing stuff like this show up they might start locking it down again.
you might be able to run proton stand-alone for stuff like this if you really want to. https://github.com/ValveSoftware/Proton
They don't care at all. They haven't done anything about SteamEmus or SteamWorks fixes ever.
> eBook DRM crackers
Which specifically? Calibre's?
Which specifically? Calibre's?
>No more struggling with wine prefixes
PlayOnLinux is a great Wine prefix manager, don't use the install scripts. It requires you to know what a wine prefix is and how to configure things.
PlayOnLinux is a great Wine prefix manager, don't use the install scripts. It requires you to know what a wine prefix is and how to configure things.
Lutris is better than PlayoOnLinux now. It has a better syntax and has more capabilities built in.
agreed, I switched from a mix of manual wine prefixes and playonlinux to all lutris. As an added benefit it makes DXVK seamless.
I did not used Lutris in a while, so let me ask if this features that I use are present now:
- installing different wine versions
- run an exe in the selected profile
- open a linux shell in the selected profile
- setting command line arguments from GUI
- setting command to run before app starts
- open winecfg, the registry for selected profile
I do not run popular games, so I do not need the Lutris scripts, though once I read one such script and run the steps manually
Lutris may be better for newbs that do not need the features I mentioned.
- installing different wine versions
- run an exe in the selected profile
- open a linux shell in the selected profile
- setting command line arguments from GUI
- setting command to run before app starts
- open winecfg, the registry for selected profile
I do not run popular games, so I do not need the Lutris scripts, though once I read one such script and run the steps manually
Lutris may be better for newbs that do not need the features I mentioned.
I think "yes" to all of those, apart from "open a linux shell".
>Ark is much better in its Proton version (the native client looks like a game from 10 years ago)
Huh, I never considered the possibility that an Unreal engine game would have such a difference depending on the operating system. Does anyone know why this is a problem for Ark, but not other games? I know Ark is particularly janky in general.
Huh, I never considered the possibility that an Unreal engine game would have such a difference depending on the operating system. Does anyone know why this is a problem for Ark, but not other games? I know Ark is particularly janky in general.
Windows' greatest strengths are also it's greatest weakness. Having a massive back catalog keeps those who need it form entirely abandoning the platform, and it also draws away talented resources needed to maintain that backward compatibility.
Supporting Proton/Wine or offering up something more official would allow them to offload that work to the community, and those who need or value that backward compatibility.
Supporting Proton/Wine or offering up something more official would allow them to offload that work to the community, and those who need or value that backward compatibility.
As ever, our problem going forward is sustainability. Compat layers are forever playing catch-up, and it's hard to take a platform seriously when it does things worse.
I'm rather disappointed in the industry's reluctance to engage with Vulkan. DX12 certainly hasn't been a runaway success either, with many devs sticking on DX11, but it seems more inevitable.
Maybe Sony can shift the balance, following Nintendo's lead by finally picking an open API (no they didn't support OpenGL on the PS3, it was a proprietary subset)... But I'd never put money on it happening.
I'm rather disappointed in the industry's reluctance to engage with Vulkan. DX12 certainly hasn't been a runaway success either, with many devs sticking on DX11, but it seems more inevitable.
Maybe Sony can shift the balance, following Nintendo's lead by finally picking an open API (no they didn't support OpenGL on the PS3, it was a proprietary subset)... But I'd never put money on it happening.
It is easy to understand.
Vulkan is stuck on C API levels, requires an expertise level that many devs aren't willing to deep dive into, it is an extension fest, with Android and GNU/Linux being the major deployment targets.
On Android it is actually an optional API since version 7, so an OEM can even release an Android 9 device without Vulkan support if they so wish and the version fragmentation is all over the board.
https://vulkan.gpuinfo.org/vulkansupport.php#android_devices
Nintendo also has their own API, NVN.
Vulkan is stuck on C API levels, requires an expertise level that many devs aren't willing to deep dive into, it is an extension fest, with Android and GNU/Linux being the major deployment targets.
On Android it is actually an optional API since version 7, so an OEM can even release an Android 9 device without Vulkan support if they so wish and the version fragmentation is all over the board.
https://vulkan.gpuinfo.org/vulkansupport.php#android_devices
Nintendo also has their own API, NVN.
Adoption of Vulkan by games targeting Microsoft Windows seems (much) more important than having native ports.
On Windows, Vulkan is only supported via the legacy ICD driver infrastrure.
Unless there is market pressure for Microsoft to support OpenGL on the store, they most likely will not address it.
Unless there is market pressure for Microsoft to support OpenGL on the store, they most likely will not address it.
For months, I've had an issue with the native Rocket League client (which is otherwise superb), where workshop maps show up as entirely black, as described here: https://steamcommunity.com/app/252950/discussions/3/17343364...
I've even tried running Steam in a Debian-based Docker container (planning a write up on this for https://blog.jeaye.com/), to see if having libtxc-dxtn-s2tc0 around would fix the problem. Alas, though I got everything running through Docker, the problem persisted (thus helping confirm it's more likely related to my nvidia driver).
Now with the latest Steam, I was able to just uninstall Rocket League, install it again with Proton enabled, and jump right in. The workshop maps render properly, the game still plays at 120 FPS, and apparently controller vibration wasn't working before, since now it rumbles every time I boost. Thank you, Valve!
I've even tried running Steam in a Debian-based Docker container (planning a write up on this for https://blog.jeaye.com/), to see if having libtxc-dxtn-s2tc0 around would fix the problem. Alas, though I got everything running through Docker, the problem persisted (thus helping confirm it's more likely related to my nvidia driver).
Now with the latest Steam, I was able to just uninstall Rocket League, install it again with Proton enabled, and jump right in. The workshop maps render properly, the game still plays at 120 FPS, and apparently controller vibration wasn't working before, since now it rumbles every time I boost. Thank you, Valve!
I'm really happy to see so much development around multi-platform game support on PCs. I use Macs for work and almost all personal computing but I still have to keep a Windows 10 PC around just for gaming. The moment that PC can be upgraded to some variety of desktop Linux while keeping all my games playable is the moment I truly become happy in life! :)
I wonder why Valve is bothering with this. People who use Linux exclusively are probably too small of a market right now for this to be a profitable endeavor. Maybe they're gearing up to revitalize SteamOS and Steam Machines?
My guess - They don't want to depend so much on Microsoft. It's a plan B in case something bad happens in the Windows ecosystem.
Why hasn't Microsoft just _bought_ Valve?
Promote cross-play between xbox and PC, give developers incentives to put out games on both platforms, and nuke the games section of the Windows store in favour of a link to Steam?
Other than legacy enterprise stuff, gaming is the one area where consumers continue to be tied to Windows. It seems like a no brainer for Microsoft to lock down that market. The average Joe/Jane that needs to do write some emails, pay bills etc. is fine nowadays with an iPad, Chromebook, etc.
Other than legacy enterprise stuff, gaming is the one area where consumers continue to be tied to Windows. It seems like a no brainer for Microsoft to lock down that market. The average Joe/Jane that needs to do write some emails, pay bills etc. is fine nowadays with an iPad, Chromebook, etc.
Always nice to hear progress on this front. It does feel like ages ago that the Windows 8 Marketplace debacle caused Valve to explore Linux gaming more seriously.
I am curious if game studios share Valve's desire for a free and open Desktop Gaming OS. I understand Valve is concerned about M$ demanding a 30% cut or locking them out of the walled garden, but game developers still just see Linux gaming as a curiosity. Proton may improve the market share, but it also kills any incentive to develop a Linux-native version.
I am curious if game studios share Valve's desire for a free and open Desktop Gaming OS. I understand Valve is concerned about M$ demanding a 30% cut or locking them out of the walled garden, but game developers still just see Linux gaming as a curiosity. Proton may improve the market share, but it also kills any incentive to develop a Linux-native version.
SteamOS isn't a free and open gaming OS. It would take a tremendous amount of design effort and integration to make a seamless interface for multiple stores to intermix. Remember Valve is in this to protect its 30% cut of sales. Its why companies with their own stores that want to rent seek on game sales have shown zero interest in supporting Linux - EA, Activision, Ubisoft, etc all have their own stores they want to push. GOG took forever to adopt Linux and even still have kept it a second class citizen by not releasing Galaxy on it.
Publishers release on Steam for Windows because they have to, not because they want to. To them, their "opponent" isn't Microsoft locking down the platform in the future but Valve controlling a lions share of that rent seeking profit from game sales today.
We can rant about how they should just distribute flatpaks of their games and use that as the runtime but at this point Valve has "claimed" the Linux space where widespread hardware adoption would probably come with SteamOS where they can never ship a game from their own store.
Publishers release on Steam for Windows because they have to, not because they want to. To them, their "opponent" isn't Microsoft locking down the platform in the future but Valve controlling a lions share of that rent seeking profit from game sales today.
We can rant about how they should just distribute flatpaks of their games and use that as the runtime but at this point Valve has "claimed" the Linux space where widespread hardware adoption would probably come with SteamOS where they can never ship a game from their own store.
That's great news and all. And I salute all the people who have put tremendous time and effort into getting Windows games to run on Linux.
Sadly, I gave up, and installed Windows on my PC, entirely replacing Linux.
I think I gave Linux gaming a good try. Some of the titles in my catalog had native ports, which generally worked well.
Some Windows titles ran under Proton (or Wine) and worked well. (Dear Ester, Valve titles obviously)
Other Windows titles had issues, ranging from the minor (glitches: The Witcher 1, GTA IV) to significant (no controller support: BioShock 1).
In some cases, as with Elder Scrolls: Skyrim, the original release runs under Proton (no controller support though), but the Special Edition currently has game-breaking issues. And installing mods for Skyrim was going to be even more of a challenge than usual.
I was spending more time trying to get things running than actually playing games, so I gave up and switched.
Sorry...
Sadly, I gave up, and installed Windows on my PC, entirely replacing Linux.
I think I gave Linux gaming a good try. Some of the titles in my catalog had native ports, which generally worked well.
Some Windows titles ran under Proton (or Wine) and worked well. (Dear Ester, Valve titles obviously)
Other Windows titles had issues, ranging from the minor (glitches: The Witcher 1, GTA IV) to significant (no controller support: BioShock 1).
In some cases, as with Elder Scrolls: Skyrim, the original release runs under Proton (no controller support though), but the Special Edition currently has game-breaking issues. And installing mods for Skyrim was going to be even more of a challenge than usual.
I was spending more time trying to get things running than actually playing games, so I gave up and switched.
Sorry...
Ironically, I find that the older a game gets the more likely it is that I'll get it working on Linux with greater ease than it would be to run it on Windows 10.
This has been my experience as well. Quite a few old games have become buggy or simply unplayable under recent Windows versions, but play fine under Wine. The most common symptom is the game becoming extremely slow on more modern DirectX iterations, which can ironically often be solved by using Wine DLLs.
There was one very ironic case with an old (1999) game that has been having issues on Win10. A long time ago, I used to run this game on Linux with Wine, and ran into a very similar issue back then, so I made a patch for the game. So I figured I'd try the same patch on Win10, and what do you know - it works.
The amusing part is that I don't remember what the patch actually does. I mean, it replaces a bunch of opcodes with NOP, but I have no idea what. I vaguely recall spending a day in IDA Pro to find those bytes, but nothing about the details.
The really amusing part is that game developers haven't figured out what the problem is, either, and so my who-knows-what-it-does patch is a semi-officially blessed solution for now:
https://steamcommunity.com/app/61500/discussions/0/215439774...
The amusing part is that I don't remember what the patch actually does. I mean, it replaces a bunch of opcodes with NOP, but I have no idea what. I vaguely recall spending a day in IDA Pro to find those bytes, but nothing about the details.
The really amusing part is that game developers haven't figured out what the problem is, either, and so my who-knows-what-it-does patch is a semi-officially blessed solution for now:
https://steamcommunity.com/app/61500/discussions/0/215439774...
Such a good series. I didn't really _feel_ it with the third, though.
Funnily, when I was trying to get a 16-bit game to run, my final (and easiest) solution was to SSH to a linux machine, run it under wine, and do X tunneling back to my Windows system.
Works like charm.
Works like charm.
DOSBox with Win 3.11 usually works well for these cases.
From what I understand, Microsoft could have totally kept 16bit application compatibility in 64bit Windows, but didn't for some reason. Apparently someone out there even compiled a version of NTVDM that works on Win 10 64-bit using leaked code or something.
From what I understand, Microsoft could have totally kept 16bit application compatibility in 64bit Windows, but didn't for some reason. Apparently someone out there even compiled a version of NTVDM that works on Win 10 64-bit using leaked code or something.
For my entire life, I have used Windows on my PC, and accessed Unix and Linux machines via PuTTY. My games and web browsers always just work, as do my programming tasks on the servers. I've never understood why this isn't recommended more. Windows and SSH, it's great!
PuTTY is not a good terminal emulator by any stretch of the imagination. I have only tolerated that setup because of emergency situations.
Fine, use your own. But PuTTY is free and easy to install, and it is enough to open the SSH connection that can then be used to launch any terminal emulator you want.
With the new Windows Subsystem for Linux you don't even have to use PuTTY anymore. The new improvements from Microsoft have come close to convincing me to switch back to Microsoft as my daily driver.
You can actually install OpenSSH natively now: https://docs.microsoft.com/en-us/windows-server/administrati...
Do games like Witcher 3 actually run well enough to be practically useful for general audiences? Or is this more for novelty?
Accoring to the user reports on https://www.protondb.com/app/292030 it seems to run very well.
Fun fact: the Kronos group added an optional Vulkan extension to simplify the implementation DX11 transform feedback.
This was requested by the DXVK developers specifically because it's was the last piece required to completely support Witcher 3.
Mesa and Nvidia had drivers support on the day (or shortly after) the extension was published.
This was requested by the DXVK developers specifically because it's was the last piece required to completely support Witcher 3.
Mesa and Nvidia had drivers support on the day (or shortly after) the extension was published.
Confusing title. I thought Proton was a negative thing.
Valve please release a 64 bit Linux client!
I am looking forward to a standalone version of Proton that I can run without having to use Steam. First, most of my games are pirated, and second, Steam is slow and clunky and I avoid using it whenever I can, even on Windows.
On the flipside, many of the games I run are from the DX9 era, and I've been using wine-d3d9[] with a high degree of success.
[]https://packages.gentoo.org/packages/app-emulation/wine-d3d9
On the flipside, many of the games I run are from the DX9 era, and I've been using wine-d3d9[] with a high degree of success.
[]https://packages.gentoo.org/packages/app-emulation/wine-d3d9
Way to show your support for the company that has done more for Linux gaming than anyone else in history, not to mention all the people who make the games you play.
I don't get how people have no problem at all stating that most of there games are pirated.
A good part is that you feel like you are not actually hurting the producer and actually you might be a net positive, as most of those people would have not spent 60$ for a game but still contribute to a lively community.
In my case many moons ago not pirating movies and games would have just meant reading more books.
Also the total disconnect between quality and price play a role sometimes.
In my case many moons ago not pirating movies and games would have just meant reading more books.
Also the total disconnect between quality and price play a role sometimes.
Nowadays $60 is enough for almost a hundred games if you buy game bundles.
Yup, but at the same time we start seeing games that are new and approaching 100 USD (some of the latest AAA games) in Digital Distribution. It's going both ways in terms of pricing, even if the median price is indeed going down.
Honestly, do I like the Gold/Ultimate/etc. editions? Not particularly (I can stomach it better if there is a minus core game cost upgrade package so I can buy the core and then if I decide I do like the game, upgrade after), but I'm not totally against increasing cost.
You've got games like Witcher 3, Red Dead Redemption 2, etc. that are basically epics: you could play them for months (amount of time spent gaming dependent). They're not epic naturally, the teams that put them together made them that way. So in that sense, I feel like you'd still come out okay shelling out for a game like that.
Likewise, graphical fidelity is approaching insane levels. Sure, applications assist in this, but at the end of the day, the developer is still spending a ton of time getting various things right visually. As such, I don't mind shelling out for that.
Dunno, as far as AAA games go, gamers have decided graphics and length of playtime are important. As an example of then vs now, Zelda used to be a game you could beat in a few hours. Breath of the Wild? Not so much. Both of these take increased development time which no one is doing for free. For them to bump up those two, price needs to go up. If it remains the same, honestly, it will eventually be unsustainable.
You've got games like Witcher 3, Red Dead Redemption 2, etc. that are basically epics: you could play them for months (amount of time spent gaming dependent). They're not epic naturally, the teams that put them together made them that way. So in that sense, I feel like you'd still come out okay shelling out for a game like that.
Likewise, graphical fidelity is approaching insane levels. Sure, applications assist in this, but at the end of the day, the developer is still spending a ton of time getting various things right visually. As such, I don't mind shelling out for that.
Dunno, as far as AAA games go, gamers have decided graphics and length of playtime are important. As an example of then vs now, Zelda used to be a game you could beat in a few hours. Breath of the Wild? Not so much. Both of these take increased development time which no one is doing for free. For them to bump up those two, price needs to go up. If it remains the same, honestly, it will eventually be unsustainable.
> A good part is that you feel like you are not actually hurting the producer and actually you might be a net positive, as most of those people would have not spent 60$ for a game but still contribute to a lively community.
Even as someone who abhors copyright as it stands, I can tell you this is bullshit thinking.
Even as someone who abhors copyright as it stands, I can tell you this is bullshit thinking.
(Just to be clear I am not interest in giving a moral justification for piracy)
Game sallers profit from piracy the same way Microsoft and Mathworks would profit from a small population of pirated copies.
you could say the same for mods, If I can mod any game in skyrim why bother having any other game on steam.
Also for most markets the number of people that buy a game after piracy is greater than the number of pirates that would have bought the game anyway (no source on this) especially if mods are hard to impossible to pirate.
Also in addition to the extremely weak arguments I have provided something similar happens in movies: https://gizmodo.com/the-eu-suppressed-a-300-page-study-that-...
UPDATE: I won't claim this is an absolute, I imagine that at least a few (indie)games were deeply damaged by piracy, especially if they were hard to buy legally or not on steam. As I said my intention is not to justify piracy, just to understand its context and consequences
Game sallers profit from piracy the same way Microsoft and Mathworks would profit from a small population of pirated copies.
you could say the same for mods, If I can mod any game in skyrim why bother having any other game on steam.
Also for most markets the number of people that buy a game after piracy is greater than the number of pirates that would have bought the game anyway (no source on this) especially if mods are hard to impossible to pirate.
Also in addition to the extremely weak arguments I have provided something similar happens in movies: https://gizmodo.com/the-eu-suppressed-a-300-page-study-that-...
UPDATE: I won't claim this is an absolute, I imagine that at least a few (indie)games were deeply damaged by piracy, especially if they were hard to buy legally or not on steam. As I said my intention is not to justify piracy, just to understand its context and consequences
I dunno, when I was in college/hs I never felt bad about pirating stuff. it's not like I would have actually paid $60 for the game if I hadn't torrented it. now that I actually make a good living from writing closed-source software, it doesn't really seem okay, so I pay for them.
If they have no problems pirating in the first place, why would they have any problem talking about it? It's not like the FBI is going to come after them. I'd rather people be honest about their actions.
[deleted]
They mentioned their games come from the DirectX 9 era. Some may be just too old to find for sale anywhere. Or they re-pirated them after purchasing a legitimate copy (I did that for Mass Effect 3).
Because people feel that DRM is an assault on the consumer.
These days you pay for the game/media, and then pirate it anyway just so you don't have to deal with the obnoxious DRM on it. (Or sometimes there's no DRM but the game is abandonware that no one can hope to trace the rightsholders of, and you can only get it reasonably by pirating it.)
Giving companies money that use DRM that drives you to pirate promotes the continued use of crippling DRM.
If you don't actually want a game in the form a distributor gives it to you at the price they ask then no, you aren't a lost sale pirating it.
At that, its not some moral black and white. I use IsThereAnyDeal to price track the games I want and only buy them at all time low prices. Mostly because I still have hundreds of titles to get around to but end up programming, drawing, or reading way too much HN all the time to get around to them.
It doesn't matter if I give a developer $1 or $0 if its still not enough to keep the lights on. The same thing happens with music and movies - you need either a sufficiently large or rich enough audience to keep your studio in the green.
Its probably way too deep for the bottom of a thread on Proton but I'm realizing that no matter how copyright is written in the post-Internet era it will always be an appeal for donation. Just because I haven't pirated a game in a decade doesn't make me "moral" or the pirate "immoral" - I only buy games now because its convenient on GOG and Steam to just have them in one place and not have to keep track of independent installers from torrents and to token support Linux developers. But I'm just an increment on a Linux sales column - I'm not actually making them anything close to reasonable revenue for the number of Linux gamers there are, and my marginal impact compared to someone who would have just grabbed it off PirateBay is completely negligible.
I'll keep buying Linux ports to... collect them? But I'm still not a valuable purchase. I'm waiting often years until its under $5 and even then I sometimes say "eh, I'll get it when its cheaper". But its not some moral high ground, and it barely impacts any bottom line - all game developers depend on first week sales at full price. Nothing else keeps the lights on, you will never see revenue volume close to that again. Buying it years later for $2 on sale is practically putting loose change in a beggars cup.
If you don't actually want a game in the form a distributor gives it to you at the price they ask then no, you aren't a lost sale pirating it.
At that, its not some moral black and white. I use IsThereAnyDeal to price track the games I want and only buy them at all time low prices. Mostly because I still have hundreds of titles to get around to but end up programming, drawing, or reading way too much HN all the time to get around to them.
It doesn't matter if I give a developer $1 or $0 if its still not enough to keep the lights on. The same thing happens with music and movies - you need either a sufficiently large or rich enough audience to keep your studio in the green.
Its probably way too deep for the bottom of a thread on Proton but I'm realizing that no matter how copyright is written in the post-Internet era it will always be an appeal for donation. Just because I haven't pirated a game in a decade doesn't make me "moral" or the pirate "immoral" - I only buy games now because its convenient on GOG and Steam to just have them in one place and not have to keep track of independent installers from torrents and to token support Linux developers. But I'm just an increment on a Linux sales column - I'm not actually making them anything close to reasonable revenue for the number of Linux gamers there are, and my marginal impact compared to someone who would have just grabbed it off PirateBay is completely negligible.
I'll keep buying Linux ports to... collect them? But I'm still not a valuable purchase. I'm waiting often years until its under $5 and even then I sometimes say "eh, I'll get it when its cheaper". But its not some moral high ground, and it barely impacts any bottom line - all game developers depend on first week sales at full price. Nothing else keeps the lights on, you will never see revenue volume close to that again. Buying it years later for $2 on sale is practically putting loose change in a beggars cup.
Whew. So I'm not sure if I'd go this route, but I empathize to a degree. I have so many games between Steam, Origin, Uplay, Battle.NET, Epic Games, and other misc. launchers that it is near impossible to keep up.
At this point, and I've said this multiple times, I really wish Microsoft had a way to create a universal launcher/downloader where if I bought a game on Uplay, it shows up in said launcher and can be downloaded from Uplay's servers. Likewise Steam and the rest. This would be better than a Movies Anywhere style program as the various storefronts don't carry almost identical libraries of games. This is a big area where console gamers win: universal game management.
At this point, and I've said this multiple times, I really wish Microsoft had a way to create a universal launcher/downloader where if I bought a game on Uplay, it shows up in said launcher and can be downloaded from Uplay's servers. Likewise Steam and the rest. This would be better than a Movies Anywhere style program as the various storefronts don't carry almost identical libraries of games. This is a big area where console gamers win: universal game management.
I disagree about steam being slow and clunky.
Just get a humble monthly subscription. For $12 a month you will never have to worry about not having enough games even if you only play on linux.
Just get a humble monthly subscription. For $12 a month you will never have to worry about not having enough games even if you only play on linux.
> I disagree about steam being slow and clunky.
It can seem to be - on my Windows 10 box, a Steam update can take half an hour or more (on the Mac, it'll never be more than a couple of minutes.)
Often it'll get stuck downloading updates to games which means you can't play them until it unsticks.
I appreciate that these are almost certainly Windows 10 issues (since a lot of other stuff is similarly afflicted) but most people will blame Steam.
It can seem to be - on my Windows 10 box, a Steam update can take half an hour or more (on the Mac, it'll never be more than a couple of minutes.)
Often it'll get stuck downloading updates to games which means you can't play them until it unsticks.
I appreciate that these are almost certainly Windows 10 issues (since a lot of other stuff is similarly afflicted) but most people will blame Steam.
> on my Windows 10 box, a Steam update can take half an hour or more
This hasn't been my experience at all. On my Windows 10 box with an aging third gen i5, a 50Mbps connection, and an SSD, Steam client updates rarely take more than a minute or two.
This hasn't been my experience at all. On my Windows 10 box with an aging third gen i5, a 50Mbps connection, and an SSD, Steam client updates rarely take more than a minute or two.
Mine is an AMD <mumblenumbers> with a 1Gbps connection and no SSD. But when Windows 10 comes back after an update, the machine will be unusable for at least an hour whilst it does <something>. Steam updates take forever. Installing Postgres the other day took about half an hour, of which at least 20 minutes was installing VC++ redistributables.
The problem with Windows 10 seems to be that it's wildly inconsistent and susceptible to the tiniest variations.
The problem with Windows 10 seems to be that it's wildly inconsistent and susceptible to the tiniest variations.
Well... It is called wine!
Yes, but I mean... Having Proton added to the repos of your distro, and being able to use it as you would use regular Wine. Because right now, it looks like you really need Steam to use Proton.
Edit: in response to ekianjo below, I can't reply: Thank you, I wasn't aware of that. I thought it was coupled with Steam tightly. I have even found a Gentoo overlay with a Proton ebuild. I'll give it a spin; I'm not a huge fan of the Linux desktop but I'm tired of Windows 10 chapping my hide with its endless stream of background processes consuming the resources of my computer while I'm trying to do something else.
Edit: in response to ekianjo below, I can't reply: Thank you, I wasn't aware of that. I thought it was coupled with Steam tightly. I have even found a Gentoo overlay with a Proton ebuild. I'll give it a spin; I'm not a huge fan of the Linux desktop but I'm tired of Windows 10 chapping my hide with its endless stream of background processes consuming the resources of my computer while I'm trying to do something else.
No, there is a git repo where you can use Proton as a separate piece of software.
WINE config wrappers for gaming aren't new, one of the better ones IME is Lutris.
I've not had much success with WINE for gaming, nor with Proton. I used to play some "Tom Clancy" games using WINE (Origin, I think it was; bought a couple of other games Rayman and something else) but the distributor changed the launcher and it never worked again. I couldn't for the life of me work out why they didn't advertise the fact their launcher worked on WINE, v. simply, nor why they would then squander that advantage by breaking that compatibility (some update loop, apparently it could be worked around but my WINE-fu wasn't up to the task).
I've not had much success with WINE for gaming, nor with Proton. I used to play some "Tom Clancy" games using WINE (Origin, I think it was; bought a couple of other games Rayman and something else) but the distributor changed the launcher and it never worked again. I couldn't for the life of me work out why they didn't advertise the fact their launcher worked on WINE, v. simply, nor why they would then squander that advantage by breaking that compatibility (some update loop, apparently it could be worked around but my WINE-fu wasn't up to the task).
People up-voting this only to read later and find out what Proton is. I thought WINE was the Windows Emulation Layer on Linux. Although, of course, Wine Is Not an Emulator.
> what Proton is. I thought WINE was the Windows Emulation Layer on Linux
Proton is just a fork of WINE[0], with a gaming focus and some Steam-specific compatibility additions.
[0] https://github.com/ValveSoftware/Proton/
Proton is just a fork of WINE[0], with a gaming focus and some Steam-specific compatibility additions.
[0] https://github.com/ValveSoftware/Proton/
Yeah, more specifically:
- DXVK, a translation layer for DX10/11 to Vulkan
- ESync
- Wine
- Proper overlay support within Steam
- DXVK, a translation layer for DX10/11 to Vulkan
- ESync
- Wine
- Proper overlay support within Steam
WINE abstracts away the operating system kernel so it is essentially a process or application VM, which is an emulator. Don't wanna argue semantics but I never understood the recursive acronym. WINE _is_ an emulator.
> WINE abstracts away the operating system kernel
WINE is an emulator to the same extent libc is an emulator, then.
WINE is an emulator to the same extent libc is an emulator, then.
It is a bit more than a library because it has a significant Runtime component, but a bit less than a full blown VM.
You could also call a drop in libc replacement that not only implements the standard but also the quirks and extensions of a specific implementation, an emulator.
You could also call a drop in libc replacement that not only implements the standard but also the quirks and extensions of a specific implementation, an emulator.
I am thinking at it from this point of view, say you create a library named libmath and you put a function in it named add.
Then someone makes an app that uses your libmath named MathApp.
If I reimplemnt libmath myself, then do some trickery to make MathApp use my version did I emulate your library or reimplement it? IMO I reimplemented it and it is very possible that my implementation could be less buggy and faster in some cases.
If I reimplemnt libmath myself, then do some trickery to make MathApp use my version did I emulate your library or reimplement it? IMO I reimplemented it and it is very possible that my implementation could be less buggy and faster in some cases.
It is an emulator, because it mimics the behaviour of the native Windows APIs. It's an abstraction layer on top of Linux syscalls, as much as libc is such an abstraction. However it's not a process virtual machine, that's provided by the kernel, and doesn't differ from what ordinary Linux processes get.
Thanks for clarifying. What is a typical example of a process virtual machine then? I'd always thought that applications that abstract away the kernel for the purposes of running software from a different OS were classic process VMs.
I guess if you'd call Java an "emulator", then you could probably do the same for Wine.
It's because when most people hear "emulator" they think of hardware emulators, which have a huge performance penalty. WINE is just translating x86 code to x86 code with minimal to no performance loss, so they want to distance themselves from the emulator label.
> translating x86 code to x86 code
My understanding is that it doesn't do any of this. Windows programs generally don't make direct syscalls, they're undocumented and only used by Microsoft-written DLLs. Wine provides a re-implementation of these DLLs suitable for Unix-like systems. The code of the program itself is untranslated and runs as-is with no performance loss.
My understanding is that it doesn't do any of this. Windows programs generally don't make direct syscalls, they're undocumented and only used by Microsoft-written DLLs. Wine provides a re-implementation of these DLLs suitable for Unix-like systems. The code of the program itself is untranslated and runs as-is with no performance loss.