ampersandrewBaldur's Gate 3 now has a native Linux build
missingnoThis is huge. I was beginning to lose hope we'd ever see a big budget high-profile non-indie get a Linux port ever again.
I know native ports are important to some folks, and I know you’re one of them, but would you mind explaining why? Maybe you’ve done so in the past and I didn’t internalize it.
Larian’s own reasoning here appears to be squeezing it for more performance, and with Linux users now accounting for 6% of English-language players, I suspect more companies will find this to be worth the effort as that percentage rises and Windows becomes more of a pain in the ass.
EDIT: reworded statistic for accuracy
fartsparklesProton still perpetuates Microsoft’s monopoly on graphics APIs etc.
There’s still plenty of other Windows-only APIs that games rely on.
Unfortunately not. The vast majority of games are DX12. Even DX11 is likely still more popular than Vulkan.
I guess, but it also simultaneously ports thousands of games that were never going to get updated with Linux builds even if Linux became 100% of the market tomorrow; several games I have now with native Linux ports are worse than the same game run through Proton. And when run through Proton, it’s no longer hitting Microsoft code. Anyway, this outcome in this post is the kind of thing that Valve expected to happen but has happened very little thus far, hopefully a sign of things to come.
Totally. And then DirectX 13 comes out and needs to be reversed and implemented, all the while developers don’t think about Linux.
If MS get cheeky with the MZ/EXE/PE format, we could be several years behind.
I’ve been using Wine for years and I think anyone who has been using it all this time will get what I’m saying.
Just because Proton/Wine has caught up (mostly) doesn’t mean it was a long and painful journey to get there.
There was a very clear dividing line between Wine before Proton and Wine after Proton. Maybe Indiana Jones and the Great Circle doesn’t work great on Proton on day 1, but it catches up so much more quickly than it used to, because there’s an incentive to. Anyway, I don’t mean to try to change your mind, and at least I get the perspective.
Again, I think you’re coming at this from enjoying Proton today but say DX13 comes out tomorrow, it could be years before Proton is compatible.
It took about 6 years for Proton to be somewhat capable at supporting DX3D 12 after it launched in 2014. Arguably it was closer to 7 or 8 years.
This is what I’m talking about. If MS purposefully make it difficult to reverse and reimplement (which they have an incentive to do), and game developers continue to focus and target MS platforms, we could be waiting half a decade to play those games on Linux.
I suppose I hardly noticed how long it took for DX12 to work because games had DX11 modes basically the entire time that Proton struggled with it. So again, not trying to sway you on anything, but optimistically, there’s going to be little to no games pushing any kind of envelope when a new technology like that comes along. It’s already prohibitively expensive for games to do so today, such that there are very few good games in a given year that make use of the latest tech.
Rainbow Six Siege, Forza 6 / Horizon 3, Halo 5, Gears of War 4, Apex Legends, Fifa 20, COD:MW (remake) are a few examples of games that launched with 12 support only.
Note how they’re the big, blockbuster games that are widely played by most non hardcore gamers.
It’d take Roblox 2, COD:69, and Footballz9000 to launch with DX3D13 only to slow down the wheels on SteamOS/Linux. When average gamers can’t pick up and play the games marketed down their throats, they’ll ditch their Steam Decks for whatever MS are pedalling.
Valve have been amazing at funding and supporting CodeWeavers the past decade but even with Valve’s practically bottomless pit of money, it took 7 years just to barely catch up to a set of APIs that haven’t changed practically since 2014.
Yeah but given that dxvk is a thing, a switch to dx13 would just need to be implemented there. The underlying wine layer would only need to change if the PE format changed. But even then, that would destroy backwards compatibility in the windows world… something that Microsoft’s enterprise customers would (rightfully) crucify them for.
I mean, UWP and Appx was a thing that happened. I doubt it’ll be the last time MS attempt to shift away from PE.
Consumers are being forced to 11 and it seems to be working. I wouldn’t be surprised to see MS bifurcate their consumer and enterprise offerings to accelerate shifts in the consumer space and catalyse shifts in enterprise.
MS have been keen to take stricter control of binaries on their platform for a long time now.
Appx and UWP are more packaging (like rpm, deb, msi) formats than an executable format. PE is behind everything in windows and the amount of effort required to change that seems truly Herculean, even for an organization the size of Microsoft. Heck, even executables for windows ARM were PE (as well as UEFI binaries). But even if you assume that they do go forward with something that insane, if they want developers to write software for it, they’ll have to publish the format specs so that gcc and llvm can implement them so that the tens of thousands of existing libraries could be ported
does this mean it will perform better on the steamdeck?
No, not really. It may, but it doesn’t necessarily. WINE + Proton doesn’t really have a performance impact, so it’s not worse than running native usually. Either one could be more performant I think, depending on the situation.
to some degree a bigger deal would be if the download was smaller.
The way I see it, native support means our platform is actually being supported.
Though it seems I may have celebrated too soon here...
Now that there is a Steam Deck Native build, is Baldur’s Gate 3 supported on Linux?
Larian does not provide support for the Linux platform. The Steam Deck Native build is only supported on Steam Deck.
Mugita SokioLarian should really support a native Linux build. Period, the end.
For what version of glibc?
Doesn’t the Steam Linux runtime have a static glibc version in it that doesn’t change?
I would be a little bit surprised if it doesn’t also work on Linux desktop. They’re probably just saying “don’t ask us to fix it if it breaks, we never said it would work”
Still lame
NateNate60The Steam Deck comes in essentially one hardware configuration with one operating system complying to one set of standards. Linux users have a higher-than-average tendency to do weird, nonstandard shit on their computers and then complain when it breaks something. On Windows, Steam OS, and Mac, if you test it on maybe 5 different configurations, you’re done. With Linux, you have to test at least four different distros (Ubuntu, Debian, Fedora, Arch), two different packaging formats for Steam (Flatpak, native package), and two windowing systems (X.org, Wayland). Plus the proprietary NVIDIA drivers along with open-source drivers. That’s already 32 combinations for 2% market share.
There is no reason they have to test it on multiple distros at all, the minimum and recommended system requirements exist for a reason. Just test it on one or two distros and list those as supported, treat anyone else the same way you would someone trying to play this game on an unsupported version of Windows like 8 or 7. If it works, great! If not - not our problem, figure it out yourself, your configuration is not supported.
That’s what they did, though, except the only distro on that list is Steam OS. And now people complain.
Why are distros and packaging formats relevant? I don’t contest that they are, but isn’t that what the steam runtime is supposed to standardize? I’m honestly baffled by the number of native steam builds that are broken in some way on my machine despite using their preferred steam runtime.
I can’t explain the exact reasons why, but let me provide some examples.
In Cities: Skylines (which is natively supported on Linux), I had two mods installed that had different behaviour depending on whether Steam was installed through a Flatpak or whether it was installed as a native package. One of them needed to access a system installation of Mono and call it (which sounds like virus behaviour, I know), and this functionality would be blocked by Flatpak’s containerisation. The second mod was a map-drawing mod which would create maps of the in-game city and put them in a specified folder in your home directory. On the native package Steam, it would put the files in the default folder, but crashes if you tried to change the directory. Otherwise, it worked as expected. On the Flatpak Steam, it would allow you to select the directory, but no files would actually be written there. It’s easy to just blame bad code written by amateur developers, but clearly it’s a case of the same code resulting in different behaviour depending on variables like Steam’s installation method.
Also, the Sims 4, which is not native and runs through Proton, worked pretty reliably on X11 but occasionally crashes mid-game using Wayland. It was not perfectly stable in either case, but it crashed far less frequently on X11 compared to Wayland.
This is not a game, but Firefox supports touchpad gestures on my laptop on Wayland, but not on X11.
Sure, but that’s kinda the point, isn’t it?
Linux has so many possible splintered ways that systems could be configured that it’s hard to support, especially when a Steam Deck native could then be adjusted to work by your userbase, without any support or testing required.
Still a win, and fair that Larian doesn’t have the budget for a full Linux release.
Norah (pup/it/she)Linux has actually hit 5-6% marketshare. Your point is still valid though, but they could always just say “It might work on other Linux builds but we can’t support them”.
Linux has 2.6% on the Steam Hardware Survey.
You can always pick one distro and architecture. “Supported on Debian 13 standard install on amd_64”. Debian being very stable (non changing) is actually a prime target for this.
Nope. If you pick the Linux version on a desktop Linux it doesn’t even have a binary, so the game can’t launch. On normal Linux you have to pick the Proton version. The Linux binary only downloads on Steam Deck.
A step in the right direction. We just gotta get the momentum going
frozenI think they fixed that, the default on desktop Linux is now the Steam Linux Runtime 3.0 and the native version of the game launches flawlessly for me on Fedora 42.
That’s awesome. I’ll definitely check it out later!
nivaThey’re probably just saying "don’t ask us
And people will ask, and will leave negative reviews when the game doesn’t work on their heavily customised setup. They are probably already writing negative reviews, just look at the comments under the OP.
That is to be expected. Which Linux should they support? Steam Deck is ok, it’s stable, new and popular. Arch? No way. Ubuntu? Yeah, no. Any other “gaming distro” some dudes built? Who would want to support that?
So what is Linux you want companies to support?
I use Arch btw.
ohshit604
ChocolateFrostedSugarBombsBut isn’t the steam deck Arch as well? So I wonder if there’s still a difference where they support just the deck specific specs…
But if it’s a Linux native build, and the deck is arch, it would stand to reason that you could at least get the build on arch. Maybe they’re doing a check against the uname or something to verify what you’re running.
I think this is perfectly fine. I dont think we should really be expecting them to provide support for the entirety of the linux platform when there is so much variation between installs. If its working on steam deck, it’ll work on linux generally.