Support us on Patreon
PayPalSad news today Linux gamers, Psyonix emailed us directly to make sure we saw the news that they're officially ending support of Rocket League on Linux and macOS.
Their published statement on this was quite short and didn't really explain much:
As we continue to upgrade Rocket League with new technologies, it is no longer viable for us to maintain support for the macOS and Linux (SteamOS) platforms. As a result, the final patch for the macOS and Linux versions of the game will be in March. This update will disable online functionality (such as in-game purchases) for players on macOS and Linux, but offline features including Local Matches, and splitscreen play will still be accessible.
If you purchased Rocket League for Mac or Linux on Steam, the game will still work with full functionality when installed and played on a computer running Windows 7 or newer.
So the Linux and macOS versions will still be there, but left old and online play will be disabled. Not good. Not good at all and as a huge Rocket League fan I'm not pleased—annoyed you might say.
This "new technologies" bit was interesting, perhaps they've decided to go DirectX 12 with an Unreal Engine upgrade? At this point we can only speculate with so little information. In the expanded support page, for Linux they mentioned playing Rocket League with Steam Play Proton is possible although they will not be supporting it.
When Psyonix became part of Epic Games back in May last year, many speculated that Rocket League would not only drop Linux support but also leave Steam. I didn't think either would happen but here we are, Psyonix has still never said they will continue to sell the game on Steam only that it would see "continued support". Originally, I thought meant it would go free to play, but with this move it seems a little more likely it will move over to the Epic Store which doesn't support Linux.
Update: Psyonix are now suggesting to request a refund from them on their support portal.
Update 2 - 24/01: Psyonix are now telling us "macOS and Linux players can reach out directly to Steam to request refunds and they will be honored. In these cases, Steam will make an exception to their 2 hours limit rule.". Their own support ticket team are now also saying to ask Steam for the refund, although Valve has denied my own refund twice.
In situations like this, Valve ideally need a better support system in place or at least an option of platform removal to get around the usual way. As we end up going in circles.
Update 3: After making their PR team aware what was going on with the refund situation, they've now released a statement on Reddit. Refunds will be accepted on Steam now, plus they gave the reason behind removing Linux and macOS support.
It's what I suspected as written above, they're upgrading to a higher version of Direct X which is a problem as the "macOS and Linux native clients depend on our DX9 implementation for their OpenGL renderer to function" and they're not willing to put resources into Vulkan/Metal for Linux/macOS when the combined player-base was apparently "0.3%" of the active total and when "viable workarounds exist" with Wine being mentioned.
They could have gone for Vulkan though to get Windows + Linux (and Stadia) and possibly even macOS with MoltenVK. It's a shame another company decided to stick with a proprietary API. That said, it may not have been possible if they're on quite an old version of Unreal Engine.
If you do get a refund for it, be sure you use that Steam Wallet funding for a developer that does support Linux. Make it count.
Article taken from GamingOnLinux.com.
appetrosyan Feb 3, 2020
Quoting: scaineQuoting: antisolQuoting: scainethink about the end-game, which is perfect, seamless support for all Windows games, on Linux.
Firstly, that's not my end-game. I'm not particularly interested in running windows games on Linux. I'd rather have Linux games.
That's the point. Once SteamPlay hits its visionary goal, there won't be any distinction.
As for the rest of your post, it's weirdly pessimistic. There are literally thousands of games I can already "play like native" and this is only the first year. In fact, there are quite a few titles that run better on Linux now than Windows 10.
Sure, the goal is visionary. And it isn't just about wine. It's about Valve and others encouraging more open development so that future titles aren't really "Windows" games anymore. It'll take years, perhaps decades, but look at the impact Vulkan has already had in such a short time. Look at DXVK that followed closely. Look at the maturity of things like SDL. It's all coming together nicely, I think.
An important point to mention is that by improving wine, you're able to fix bugs to games that are otherwise frozen in a non-playable state. You can make a specific patch that averts a specific sys call from segfaulting. Doing the same using SDL without access to the source code, would only incur additional overhead. More importantly, instead of the decision of what works and what doesn't being down to the technologies used, you now incorporate elements of corporate politics. Bethesda's games will never feature an SDL client, having no Proton, leaves them to decide, if we get to play Doom Eternal, or TES VI. With proton, they need to actively work against supporting it, to make it incompatible.
slaapliedje Feb 7, 2020
Quoting: appetrosyanActually wine can and does run 20 year old games better than Windows 10 can. Because in wine you can actually set the version of Windows you wish to pretend to be (also known as emulation, but I know it isn't emulation, it is a compatibility wrapper, much like Glide is a wrapper for the 3Dfx API into OpenGL.)Quoting: antisolQuoting: scainethink about the end-game, which is perfect, seamless support for all Windows games, on Linux.
Firstly, that's not my end-game. I'm not particularly interested in running windows games on Linux. I'd rather have Linux games.
Secondly, the idea of having perfect, seamless support for all Windows games is a pipe dream that will never happen unless Microsoft opens up the relevant tech (directx, win32 api or whatever the modern equivalent is), which they will absolutely never do. Even if they did you're only going to get up tp ~95% compatibility. Without the specs (at least) for these techs being open it's always going to be a reverse-engineering effort where you're playing whack-a-mole with new versions of APIs. If you think that this is a reasonable goal you're just setting yourself up for disappointment.
You're not going to get perfect support for all windows games under wine. Not ever. This is the nature of emulation. 100% is not achievable, even with open specs and non-moving targets. Attempting it with windows is bold and commendable but ultimately futile and laughable. Wine can't even run the ~20 year old stuff that I want to run.
This comment highlights a common misconception that plagues all of these discussions.. For the LAST TIME, WINE = WINE IS NOT an EMULATOR.
Reverse engineering, can and often does work better than having access to the source code, provided enough dedication and good enough platforms: nblood vs blood fresh supply is a good example of a reverse engineered lovingly crafted engine doing better than a commercial port.
Wine can't run things that are 20years old, may be up to the projects themselves, and it's highly likely that windows 10 can't either. At this stage the only thing that does actually make more sense to do is to think of the distant future. Apple just deprecated 90% of all games that have a Mac version, because of stubbornly removing 32-bit libraries. A similar thing can and might very well happen on Windows, and on Linux, we have averted the catastrophe once, we can avert it again. I'm positive that at some point, the libraries will be deprecated so badly that we'll simply be bundling them as part of retro gaming, much like we do now for the 8/16 bit stuff. This, you will never be able to do, if you've never ventured into emulation.
A pipe dream it might be, but I'm happy with the vertical slice of games that can reliably be played through wine. I'm also a bit unhappy with the state of "native" games with proprietary licenses.
Wine, the great Pretender!
Quoting: slaapliedjemuch like Glide is a wrapper for the 3Dfx API into OpenGLJust a little nitpick: While there are several wrappers, Glide is actually the name of the 3Dfx API itself.
slaapliedje Feb 7, 2020
Quoting: tuubiHa, well in my defense, it's been like 20 years since I used it.Quoting: slaapliedjemuch like Glide is a wrapper for the 3Dfx API into OpenGLJust a little nitpick: While there are several wrappers, Glide is actually the name of the 3Dfx API itself.
nGlide was the one I was probably thinking of.
It's fun trying to describe to people the difference between emulation, library wrappers and something like FPGA though.
'FPGA is emulation!'
'No, FPGA is hardware recreation.'
'So, emulation?'
'No, it's actual hardware, that is told to act like a specific piece of hardware.'
'So, emulation?'
'no...
'But it's not the same thing!!'
'It's still hardware!'
'But.. it's not the original hardware, so it's emulating it!'
*punches* 'Well, one more non-believer is down...'
Ha, watching the arguments for the Vampire boards for the Amiga is entertaining.
appetrosyan Feb 15, 2020
Quoting: slaapliedjeQuoting: appetrosyanActually wine can and does run 20 year old games better than Windows 10 can. Because in wine you can actually set the version of Windows you wish to pretend to be (also known as emulation, but I know it isn't emulation, it is a compatibility wrapper, much like Glide is a wrapper for the 3Dfx API into OpenGL.)Quoting: antisolQuoting: scainethink about the end-game, which is perfect, seamless support for all Windows games, on Linux.
Firstly, that's not my end-game. I'm not particularly interested in running windows games on Linux. I'd rather have Linux games.
Secondly, the idea of having perfect, seamless support for all Windows games is a pipe dream that will never happen unless Microsoft opens up the relevant tech (directx, win32 api or whatever the modern equivalent is), which they will absolutely never do. Even if they did you're only going to get up tp ~95% compatibility. Without the specs (at least) for these techs being open it's always going to be a reverse-engineering effort where you're playing whack-a-mole with new versions of APIs. If you think that this is a reasonable goal you're just setting yourself up for disappointment.
You're not going to get perfect support for all windows games under wine. Not ever. This is the nature of emulation. 100% is not achievable, even with open specs and non-moving targets. Attempting it with windows is bold and commendable but ultimately futile and laughable. Wine can't even run the ~20 year old stuff that I want to run.
This comment highlights a common misconception that plagues all of these discussions.. For the LAST TIME, WINE = WINE IS NOT an EMULATOR.
Reverse engineering, can and often does work better than having access to the source code, provided enough dedication and good enough platforms: nblood vs blood fresh supply is a good example of a reverse engineered lovingly crafted engine doing better than a commercial port.
Wine can't run things that are 20years old, may be up to the projects themselves, and it's highly likely that windows 10 can't either. At this stage the only thing that does actually make more sense to do is to think of the distant future. Apple just deprecated 90% of all games that have a Mac version, because of stubbornly removing 32-bit libraries. A similar thing can and might very well happen on Windows, and on Linux, we have averted the catastrophe once, we can avert it again. I'm positive that at some point, the libraries will be deprecated so badly that we'll simply be bundling them as part of retro gaming, much like we do now for the 8/16 bit stuff. This, you will never be able to do, if you've never ventured into emulation.
A pipe dream it might be, but I'm happy with the vertical slice of games that can reliably be played through wine. I'm also a bit unhappy with the state of "native" games with proprietary licenses.
Wine, the great Pretender!
Quoting: slaapliedjeQuoting: appetrosyanActually wine can and does run 20 year old games better than Windows 10 can. Because in wine you can actually set the version of Windows you wish to pretend to be (also known as emulation, but I know it isn't emulation, it is a compatibility wrapper, much like Glide is a wrapper for the 3Dfx API into OpenGL.)Quoting: antisolQuoting: scainethink about the end-game, which is perfect, seamless support for all Windows games, on Linux.
Firstly, that's not my end-game. I'm not particularly interested in running windows games on Linux. I'd rather have Linux games.
Secondly, the idea of having perfect, seamless support for all Windows games is a pipe dream that will never happen unless Microsoft opens up the relevant tech (directx, win32 api or whatever the modern equivalent is), which they will absolutely never do. Even if they did you're only going to get up tp ~95% compatibility. Without the specs (at least) for these techs being open it's always going to be a reverse-engineering effort where you're playing whack-a-mole with new versions of APIs. If you think that this is a reasonable goal you're just setting yourself up for disappointment.
You're not going to get perfect support for all windows games under wine. Not ever. This is the nature of emulation. 100% is not achievable, even with open specs and non-moving targets. Attempting it with windows is bold and commendable but ultimately futile and laughable. Wine can't even run the ~20 year old stuff that I want to run.
This comment highlights a common misconception that plagues all of these discussions.. For the LAST TIME, WINE = WINE IS NOT an EMULATOR.
Reverse engineering, can and often does work better than having access to the source code, provided enough dedication and good enough platforms: nblood vs blood fresh supply is a good example of a reverse engineered lovingly crafted engine doing better than a commercial port.
Wine can't run things that are 20years old, may be up to the projects themselves, and it's highly likely that windows 10 can't either. At this stage the only thing that does actually make more sense to do is to think of the distant future. Apple just deprecated 90% of all games that have a Mac version, because of stubbornly removing 32-bit libraries. A similar thing can and might very well happen on Windows, and on Linux, we have averted the catastrophe once, we can avert it again. I'm positive that at some point, the libraries will be deprecated so badly that we'll simply be bundling them as part of retro gaming, much like we do now for the 8/16 bit stuff. This, you will never be able to do, if you've never ventured into emulation.
A pipe dream it might be, but I'm happy with the vertical slice of games that can reliably be played through wine. I'm also a bit unhappy with the state of "native" games with proprietary licenses.
Wine, the great Pretender!
While that is mostly true there are some exceptions. My point was that even conceding that Wine cannot do more than Windows, then it is still a valuable asset!
See more from me