Half-Life remake Black Mesa has a big upgrade with DXVK 2.3.1, optimizations and bug fixes

Thank GOD! Black Mesa has been broken forever on Linux and you had to manually change to Proton in order to fix the issues. Hopefully they fix that and the controller support, which should be a lot better now.

Wine/Proton/DXVK are such performant today's on Linux, unlike native Linux games which age poorly: library dependency problems or are not up to date because the developers do not maintain them.
At the same time I put myself in the developers' shoes, it's much more economical and less complicated to maintain a single version of the game, the one for Windows, and to make it Wine/Proton/DXVK compatible.

This is also a perverse effect of the effectiveness of WIne/Proton/DXVK, is that it does not encourage the development of native Linux games. But the main thing is that Linux gamers can simply play their games, without worrying if it's a Windows version or not and without having to tinker too much like we did only a few years ago.


Last edited by legluondunet on 16 April 2024 at 9:30 am UTC

Tried this more than a year ago on the Deck, and couldn't get comfortable with controls. So the controller support and Steam Input integration is a really welcome addition, will give it another try!

Yeah, I played it a few months ago and I got crashes in the xen world on both the native Linux version and the windows version with proton. I switched back and forth a couple of times to figure out which worked better. I'd much rather have just one that actually works.
I think the windows version worked better for me, but I might misremember.


Last edited by Holzkohlen on 16 April 2024 at 10:31 am UTC

The power of open source: running, through an open source compatibility layer, the proprietary operating system's version of a proprietary game using an engine built partially around open source libraries (and that uses part of said compatibility layer), even though we have functional builds of said libraries on the target platform (which is THE open source flagship). Oh, the irony... but Xzibit would be proud . And dxvk-native is still a thing (upstreamed).

Realistically speaking, what could be so bad if Proton became the de-facto Linux support method for all games, including games that would've had Native Linux support if the developers were generous enough? I'm a new Linux user and I've been thinking about this.

Asking for native ports is chasing a wild goose, to fix this issue you'd have to go to the source of it: user market share, until Linux becomes figuratively mainstream, that's when asking for native ports becomes logical and feasible, in my opinion.

I said it once and i say it again. Proton is one of the best and worst things that happend to Linux Gaming. Thanks to Proton all the devs just take the lazy route instead of making a Native version. And if a game had a Native version they now want to replace it with Proton.

What a disaster. They didn't even consider using dxvk-native.

Oh, but they (kind of) did because they now use DXVK dll to translate d3d9 to vulkan in their Windows build...

Realistically speaking, what could be so bad if Proton became the de-facto Linux support method for all games, including games that would've had Native Linux support if the developers were generous enough?

Because in practice, proton "support" often means ignore it and let Valve deal with any issues. I think I can count the number of devs that actually fixed something to get it running better (or at all) on proton on one hand.

Realistically speaking, what could be so bad if Proton became the de-facto Linux support method for all games, including games that would've had Native Linux support if the developers were generous enough?

Because in practice, proton "support" often means ignore it and let Valve deal with any issues. I think I can count the number of devs that actually fixed something to get it running better (or at all) on proton on one hand.

I see, though I think that can also be applied to Linux Native ports too, no? whenever they get broken, fixes are usually rare from what I read, I'm asking here because like I said, I'm new and I wouldn't know how native ports went, what I hear nowadays is that the majority of the native builds are broken/worse than if with Proton.

So let me reiterate my question: From what I see, the work required to maintain 2 different versions of a game is generally too great for most dev teams, when taking into account the financial cost behind this. Call it laziness or whatever. Native Linux ports are a rarity, and so, Proton appears to be the reality we're going to have to accept, for better or worse. So, what is worse here? Bearing in mind that the only scenario where we start getting properly supported ports is if the market shifts to Linux (never).

I think the number of devs who'd fix something in Proton is the same number of whom would bother to make a native build anyways. And if Proton is easier to deal with, what could be the downsides? this is basically asking my original question again but better.

I see, though I think that can also be applied to Linux Native ports too, no? whenever they get broken, fixes are usually rare from what I read, I'm asking here because like I said, I'm new and I wouldn't know how native ports went, what I hear nowadays is that the majority of the native builds are broken/worse than if with Proton.

Yes, this does happen. Numerous Linux ports have been completely abandoned, left to rot, or dropped entirely.

At least with Proton, being open source (and based on Wine), the maintained version can continue to be improved upon using it.

Realistically speaking, what could be so bad if Proton became the de-facto Linux support method for all games, including games that would've had Native Linux support if the developers were generous enough? I'm a new Linux user and I've been thinking about this.

There are a few practical issues with WINE/Proton that are more or less unsolvable by design:

- Slower startup times (compare `wine simple_program.exe` with `./simple_program` of a native Linux binary). This is especially the case if the WINE prefix needs to be updated following a WINE update, in which case it can take 10+ seconds.
- Larger file size – a WINE prefix isn't small, especially if you use one prefix per game. WINE updates often tend to dominate in terms of file size compared to other programs (at least if you use system WINE, but it's a similar deal with Proton). I think only LaTeX competes here in terms of large updates in distribution repositories :)

These are not dealbreakers for gaming, but a native port is still ideal when it's well-maintained.


Last edited by Calinou on 16 April 2024 at 4:40 pm UTC

Whoa, may be i will be able to play game i paid for?

And if Proton is easier to deal with, what could be the downsides?

Honestly not much but it used to be a bigger pain in the butt until VERY recently. Before, you had to install a game, then select a Proton version, then boot it up, then see what's missing, then use Winetricks to install the missing dependencies, then rinse and repeat until the game finally works. Mind you, this is ignoring the fact that game-breaking bugs could show up mid-session so you'd have to exit the game and find out what the problem was online.

Nowadays, 99% of games work with the latest version of Proton out of the box and the ones that don't are either never intended to work (like multiplayer games with invasive anti-cheat) or listed on ProtonDB with very quick fixes.

What a disaster. They didn't even consider using dxvk-native.

Ultimately though, even if I have gotten well accustomed to Source games over the years, screw that engine. There's no winning with Linux ports of Source games, nearly all of them have unique issues, and the engine is stuck in the 2000s so hard.

Sure, Valve started fixing up some of their Source-based games on Linux a few years ago, but it doesn't seem that most community projects can leverage the upgrades.

DXVK-Native has since been integrated into mainline DXVK starting in Version 2.0 going forward, developers can port their DX9-DX11 game to DXVK if they want to.

and given selected Valve games (Source, not to be confused with Source 2) now uses DXVK renderer by default (on Steam Deck) instead of ToGL and Black Mesa uses the same (despite being heavily modified) engine, I lowkey expect the Linux build of Black Mesa to operate the same as selected Valve games already does on Linux by now.


Last edited by AL2009man on 16 April 2024 at 8:46 pm UTC

At least with Proton, being open source (and based on Wine), the maintained version can continue to be improved upon using it.

True. So in a sense, there's a potential for better longevity with Proton vs Native, actually. Being open source should mean there's always those who are passionate and skilled who can work to make a game continue to work, that and, you know, Valve, being obligated to keep ensuring whatever they sold on the Steam Deck continues to work.

There are a few practical issues with WINE/Proton that are more or less unsolvable by design:

- Slower startup times (compare `wine simple_program.exe` with `./simple_program` of a native Linux binary). This is especially the case if the WINE prefix needs to be updated following a WINE update, in which case it can take 10+ seconds.
- Larger file size – a WINE prefix isn't small, especially if you use one prefix per game.

Great points. I never realised that going with Proton means a slower startup, I think it's because it is pretty fast already, but obviously native should launch even faster.

The large file size is definitely an issue, and I suspect it'll become even more prominent over time as I keep downlaoding different version of Proton/Wine. Though I imagine in the future we should reach a point where only one Proton version is needed for virtually everything on Steam. And a select few for edge cases outside of Steam. I wonder if it's also possible to reduce Proton/Wine prefix's filesize too.

Honestly not much

Yeah, I've just been thinking about it and thought it was interesting. "Okay, we're stuck with this "hack" to play our games, what could actually be so bad about it if that's the case?" And so far it doesn't look too bad, which is reassuring.

I think I can count the number of devs that actually fixed something to get it running better (or at all) on proton on one hand.

Rockfish Games being one of them for Everspace 2

The large file size is definitely an issue, and I suspect it'll become even more prominent over time as I keep downlaoding different version of Proton/Wine. Though I imagine in the future we should reach a point where only one Proton version is needed for virtually everything on Steam. And a select few for edge cases outside of Steam. I wonder if it's also possible to reduce Proton/Wine prefix's filesize too.

I would guess that the new, not enabled by default yet, WoW64 mode in Wine would cut down quite a bit on prefix size, and possibly also on prefix creation time.

There was also some interesting patches for reflink but I'm not sure if that work was ever completed?

"When reflink is supported by the underlying filesystem, new Wine prefix
sizes with Mono and Gecko disabled are reduced to less than 1 MB."

From https://www.winehq.org/pipermail/wine-devel/2021-August/193357.html

I think I can count the number of devs that actually fixed something to get it running better (or at all) on proton on one hand.

Rockfish Games being one of them for Everspace 2

To be honest, that was expected with the pretty good linux support on the first one and the broken promise of a linux port for the second.