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