For those of you playing on Steam Deck, Baldur’s Gate 3 now also features a native Steam Deck build!
Running natively on the platform, you should now see a better framerate, lower loading times, and smoother gameplay 🙌
The store page hasn’t updated yet, but you can see the Linux Steam depots on steamdb.
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”
The 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.
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”.
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.
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.
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.
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.
EDIT: This is no longer true. If you simply disable the compatibility modes, the native steam deck now downloads nicely on Linux, and it runs straight out of the box for me, and with much less stuttering
I 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.
I don’t like that Steam can do this. If I force BG3 to use the Sniper runtime, then it should be the same exact build that gets downloaded to the Steam Deck.
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?
But 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.
You can promise support for ’xyz’ distro and advertise that which is what Larian is doing however, if they said they supported Debian for example than that would open a whole can of issues as a lot of distributions are Debian based.
Would be nice to have Debian and Arch be the foundation for Linux based game development and make that the standard throughout all the other distros like SteamOS, LinuxMint or PopOS. Fedora is kinda in their own world I suppose.
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.
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.
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 12 launched in 2014. Arguably it was closer to 7 or 8 years (that’s how long Proton took to get to the state it’s in today).
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.
Playing catchup forever isn’t sustainable. Proton is a stop-gap while Valve try and shift an industry away from a behemoth. Native is the end goal, not maintaining middleware and a creaking stack of patches.
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
For me, it shows that they actually care to support Linux. It doesn’t really materially change anything, but to does show a sign that they’re putting real effort in to support the growing Linux population, rather than just ignoring it and hoping Proton handles it.
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.
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.
This 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.
Edit: Maybe not that huge…
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
The 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.
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.
Maybe it’s just because I use Bazzite and that’s so close to SteamOS, that things that work on Deck generally work on my laptop.
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.
Pretty sure both examples are just lack of perms on te flatpak
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.
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.
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.EDIT: This is no longer true. If you simply disable the compatibility modes, the native steam deck now downloads nicely on Linux, and it runs straight out of the box for me, and with much less stuttering
I 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!
How can you install the Linux version? I don’t See an Option in steam.
Right click on Baldur’s Gate 3 -> Properties… -> Compatibility
You can either remove the check mark in “Compatibility” completely or set it to “Steam Linux Runtime 3.0”.
Unless your force a Proton version, the game will use the Linux version automatically.
I don’t like that Steam can do this. If I force BG3 to use the Sniper runtime, then it should be the same exact build that gets downloaded to the Steam Deck.
A step in the right direction. We just gotta get the momentum going
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.
deleted by creator
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.
You don’t have to support any specific Linux, valve provides all the necessary runtimes
https://gitlab.steamos.cloud/steamrt/steamrt/-/blob/steamrt/scout/README.md
But 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.
Support doesn’t have to be based on a specific distro. It isn’t for any of the other ports that support us.
When you promise support, you have to take responsibility when it doesn’t work.
You can promise support for ’xyz’ distro and advertise that which is what Larian is doing however, if they said they supported Debian for example than that would open a whole can of issues as a lot of distributions are Debian based.
Would be nice to have Debian and Arch be the foundation for Linux based game development and make that the standard throughout all the other distros like SteamOS, LinuxMint or PopOS. Fedora is kinda in their own world I suppose.
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
Proton still perpetuates Microsoft’s monopoly on graphics APIs etc.
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 wasn’t 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 12 launched in 2014. Arguably it was closer to 7 or 8 years (that’s how long Proton took to get to the state it’s in today).
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.
Playing catchup forever isn’t sustainable. Proton is a stop-gap while Valve try and shift an industry away from a behemoth. Native is the end goal, not maintaining middleware and a creaking stack of patches.
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
Yeah but linux native builds break even with the steam runtime…
Aren’t most games on Vulkan these days?
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.
A lot of engines support Vulkan builds, but the default is DX. Almost every game is DX.
The way I see it, native support means our platform is actually being supported.
Though it seems I may have celebrated too soon here…
For me, it shows that they actually care to support Linux. It doesn’t really materially change anything, but to does show a sign that they’re putting real effort in to support the growing Linux population, rather than just ignoring it and hoping Proton handles it.
does this mean it will perform better on the steamdeck?
Yes
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.
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.
Larian 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?