Monster Hunter Rise has just released on Steam today from Capcom and the good news is - it appears to run very nicely out of the box with Steam Play Proton on Linux. That's another tick in the box for a big AAA title.
Tested with Proton Experimental, the only issue currently encountered is a small intro video not playing. This is a reoccurring issue and will be for the Steam Deck, for titles that use things like Media Foundation. If such things bother you, it worked just fine with Proton GE which you can easily download with ProtonUp-Qt. Over time though, Valve will be re-encoding videos for games where it's an issue so eventually more won't see this issue. Luckily here it's really minor.
Direct Link
I haven't been able to see any obvious issues, there isn't even much stutter which you would usually see from a brand new release on Linux. Then again, it's not as a graphically intense as certain other big releases, since this was originally developed for the Nintendo Switch so it's really not all that surprising.
Overall, a pretty smooth release to be able to play at release on Linux with Proton.
You can try it out yourself right now too, as there's a demo on Steam. Also available on Humble Store.
Tested with Proton Experimental, the only issue currently encountered is a small intro video not playing. This is a reoccurring issue and will be for the Steam Deck, for titles that use things like Media Foundation.I hope this won't be an issue for the Steam Deck; that they'll have rolled out their re-encoding solution by the time the Deck ships.
Tested with Proton Experimental, the only issue currently encountered is a small intro video not playing. This is a reoccurring issue and will be for the Steam Deck, for titles that use things like Media Foundation.I hope this won't be an issue for the Steam Deck; that they'll have rolled out their re-encoding solution by the time the Deck ships.
They already have. The problem is that it takes time before the re-encoded videos appear.
I hope this won't be an issue for the Steam Deck; that they'll have rolled out their re-encoding solution by the time the Deck ships.
I haven't followed too closely; does anyone know the (technical? legal?) issues with the solution used in ProtonGE?
I hope this won't be an issue for the Steam Deck; that they'll have rolled out their re-encoding solution by the time the Deck ships.
I haven't followed too closely; does anyone know the (technical? legal?) issues with the solution used in ProtonGE?
GE just takes the library from Windows to decode those files. That's at least copyright infringement if you don't have a licence for that software on the machine you're running it on. Likely patent infringement, too (since that can be a thing for software despite it making no sense), given that Valve haven't taken the reimplementation approach.
I hope this won't be an issue for the Steam Deck; that they'll have rolled out their re-encoding solution by the time the Deck ships.
I haven't followed too closely; does anyone know the (technical? legal?) issues with the solution used in ProtonGE?
GE just takes the library from Windows to decode those files. That's at least copyright infringement if you don't have a licence for that software on the machine you're running it on. Likely patent infringement, too (since that can be a thing for software despite it making no sense), given that Valve haven't taken the reimplementation approach.
I think it's not so much about copyright infringement as it is about the right to distribute the library on its own, i.e. not as part of a Windows installation. Lots of Windows libraries have this issue, and the solution has always been to find a freely distributable executable somewhere on the internet that already contains the required dll's in a distributable form (which could be anything, from an old Firefox installer to a Microsoft SQL Server trial to an old game's patch file) and use that to obtain the dll's in a legally gray way. That's the reason Winetricks downloads all kinds of weird stuff into its cache folder when doing its thing.
This is a strategy that has worked very well for pretty much everything so far, with the sole exception of Media Foundation: there is simply no freely distributable executable out there that contains the needed dll's (or rather, there exists one for the Windows 7 dll's, but Wine and especially Proton have long since switched to Windows 10 by default for various reasons, one of them being DX12, so that Windows 7 executable is pretty much useless).
Now, Valve has its hands tied because it's a large corporate entity and it would be the target of a lawsuit the moment it tried to illegally distribute any Windows library - but Proton GE doesn't have this issue (or rather, it's a small enough fish that it doesn't care about it) and... that's about it in a nutshell.
P.S. - There's been an ongoing attempt to re-implement WMF in Wine for more than a year now, and large parts of this work have already been merged into Wine Staging, so Valve has definitely considered the re-implementation approach; and it wouldn't surprise me if this re-encoding solution is only meant to be a temporary stopgap until they've finished re-implementing WMF.
But unfortunately, what would be even less of a surprise to me at this point is if it turned out that they've ended up opting for the re-encoding solution due to some kind of headbutting with Wine upstream, just like what has already happened with DXVK and more recently with futex_waitv. Wine upstream is proving to be more than annoying in that regard, to say the least.
Last edited by Nocifer on 13 January 2022 at 4:46 pm UTC
I think it's not so much about copyright infringement as it is about the right to distribute the library on its own
So basically Copyright infringement ;)
kind of headbutting with Wine upstream, just like what has already happened with DXVK and more recently with futex_waitv. Wine upstream is proving to be more than annoying in that regard, to say the least.No headbutting with Wine upstream for futex_waitv.
The person who explained that fsync is unsuitable for Wine upstream is the person who wrote esync, and fsync, and suggested and is writing an implementation for the real solution winesync.
The problem is twofold:
1. Implementing the api in Wine, this is a work in progress but seems to progress nicely.
2, Decoding the actual video. On a normal Wine install, decoding uses whatever copy of ffmpeg (via Gstreamer) and works because most distributions take a don't ask-don't tell approach to the problem. Proton doesn't use your system libraries and Valve can't legally ship a usable ffmpeg for fear of infringing on the video patents.
https://twitter.com/Plagman2/status/1481451939787251713
CDPR did the same with Cyberpunk 2077, but in that case the problem was that it was Cyberpunk 2077.
See more from me