1035
Baldur's Gate 3 now has a native Linux build (bsky.app)
submitted 11 months ago by to c/linux_gaming@lemmy.world
113 comments fedilink hide all child comments
 

The store page hasn't updated yet, but you can see the Linux Steam depots on steamdb.

you are viewing a single comment's thread
view the rest of the comments
[–] [S] 34 points 11 months ago (9 children)

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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 9 child comments
    •
  • [–] 20 points 11 months ago* (last edited 11 months ago) (8 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] [S] 8 points 11 months ago (3 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 11 points 11 months ago* (2 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] [S] 7 points 11 months ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 points 11 months ago*

    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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 4 points 11 months ago (2 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 11 months ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 11 months ago

    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

  • permalink
  • fedilink
  • source
  • parent