Live data from Hacker News

Baldur's Gate 3 Steam Deck – Native Version

larian.com

361–370 of 462 posts

Re: Baldur's Gate 3 Steam Deck – Native Version

#361
post #174

This is a gigantic effort from Larian, who among all things is still updating its software instead of resting on its own laurels. But the Deck is limited in hardware. It makes sense that it has some difficulties running gigantic games and is more aimed towards simpler games. In parallel I don't understand gamers with 15 years old hardware leaving bad reviews or whining when a game chokes above 720p with minimum setti…

> In parallel I don't understand gamers with 15 years old hardware leaving bad reviews or whining when a game chokes above 720p with minimum settings.

IMO it's because a lot of these newer games just don't need that much horsepower. BG3 is not one of them, but looking at the broader industry.

A lot of times were seeing maaaaaybe a 5% bump in fidelity or graphics quality in exchange for 400% less performance.

Like ray tracing. Does Ray tracing look good? Yes. But not that good. Its not the PS1 to the PS2. I've seen baked lighting indistinguishable from Ray tracing in 99% of scenes.

Its just not a good trade off with modern games usually. Unless they really optimize them.

The only people still optimizing games is Nintendo from what I've seen.

Re: Baldur's Gate 3 Steam Deck – Native Version

#362
post #172

If there was ever a game to play with KB+M, this is it. I don't get the need to stuff everything into a handheld. It's not Mario kart!

You've got two trackpads, gyro, 4 extra buttons on the back to bind, and Steam Input lets you make custom radial (or non-radial) menus with entries that can press any keyboard key or key combo for you (which you can bind to the trackpads). It's honestly nothing like using an Xbox controller if that's what you're imagining.

Mario Kart is also a funny example as it's one of the few racing games that makes no use of analog triggers for acceleration, so you really wouldn't miss much playing it on a keyboard.

Re: Baldur's Gate 3 Steam Deck – Native Version

#363

Earlier quoted context omitted.

Time to link the famous “Win32 Is The Only Stable ABI on Linux” https://blog.hiler.eu/win32-the-only-stable-abi/ 500 comments https://news.ycombinator.com/item?id=32471624

Correct me if I'm wrong, but I don't think that's an entirely fair comparison? The syscall abi has been stable for decades, and any game that included glibc or compiled with musl keeps running just fine?

You need to include not just glibc, you also need to include ld.so sometimes, because older libs can become incompatible with current ld.so (Linux port of SMAC for example), and I fear what it might do sometimes when trying to link openGL or Vulkan driver that links to newer glibc.

Re: Baldur's Gate 3 Steam Deck – Native Version

#364
post #232

Earlier quoted context omitted.

That's kind of the state of Linux in general. Binaries need to be build against the correct distribution and version. Even static binaries are a gamble.

Steam takes care of the distribution and version mumbo jumbo for you with their runtime https://github.com/ValveSoftware/steam-runtime https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/b...

Thanks, this is very interesting. So the old native runtime was basically a messy hacky using LD_LIBRARY_PATH and Ubuntu 12.04 libraries, and now they're using containers based on Debian 10 (Steam Runtime 2 'soldier') or Debian 11 (Steam Runtime 3 'sniper').

Edit: Valve actually have some very interesting documents about their compatibility environments:

- https://github.com/ValveSoftware/steam-runtime/blob/master/d...

- https://gitlab.steamos.cloud/steamrt/steamrt/-/blob/steamrt/...

- https://gitlab.steamos.cloud/steamrt/steamrt/-/blob/steamrt/...

- https://gitlab.steamos.cloud/steamrt/steamrt/-/blob/steamrt/...

Re: Baldur's Gate 3 Steam Deck – Native Version

#365

Earlier quoted context omitted.

Yes but that limits you to command line applications. GL and X11 (and I assume Wayland) are always linked dynamically. Granted, those don't suffer from glibc's "DLL version hell", but not sure what happens when you link the main executable statically against musl and then load DLLs which dynamically link glibc. Another option is to dynamically link against an old glibc version, the Zig toolchain makes that easy also…

glibc doesn't suffer from DLL version hell as long as you are not doing anything stupid (like using private symbols). If you commit to using just the "C library" bits you can compile a binary linked against glibc on a distro from 1998 and it will work on modern distros just fine. There are many issues with libraries breaking backwards compatibility on Linux (like pretty much all GUI ones) but glibc, X11, OpenGL (and…

glibc very much suffers from version hell, because:

a) glibc will drop older versioned symbols over time making your binary not work at all

b) glibc owns ld.so and is not afraid to make incompatible changes, which is why running Sid Meyer's Alpha Centauri linux port requires that you dig out not just libc, but the entire dynamic linking stack and know how to bypass default executable interpreter in ELF files.

Re: Baldur's Gate 3 Steam Deck – Native Version

#366

Earlier quoted context omitted.

Native doesn't automatically mean better - quite a few examples of games running better on proton than with native executables(and yes then we can start arguing that it just means the native port is done poorly, but I'm just saying don't assume native will always run better).

It seems like a similar argument around the popularity of third party engines, whether studios should use Unreal, or whether they have the expertise/resources to change to and use another engine, or make their own bespoke engine, and if that will produce better results.

I think that is not fair comparison. Proton adds additional layer which can be completely removed and affects the runtime performance. Switching different game engine changes the layer implementation, instead of removing.

Re: Baldur's Gate 3 Steam Deck – Native Version

#367

Earlier quoted context omitted.

glibc doesn't suffer from DLL version hell as long as you are not doing anything stupid (like using private symbols). If you commit to using just the "C library" bits you can compile a binary linked against glibc on a distro from 1998 and it will work on modern distros just fine. There are many issues with libraries breaking backwards compatibility on Linux (like pretty much all GUI ones) but glibc, X11, OpenGL (and…

Last I tried the problem was linking against glibc on a new Linux distro and then attempting to run that executable on an old Linux distro which doesn't have a recent-enough glibc installed (usually Debian with their software stack from the last century). There's probably an obscure linker trick to force an older glibc version number, but if that's the case it really should be the default since the C stdlib is suppos…

This isn't just a glibc thing but something you can find with any shared library on Linux. For example if you are using a rolling distro and make a build that links against Qt6, the produced binary may not work in another distro that has a slightly older Qt6.

As palata mentioned the "trick" is to build using the oldest version you plan to target. You can use a Docker image with, say, Debian (which has official docker images going back to Squeeze released in 2011) to build the binary and release that.

AFAIK there are some tools that allow you to fudge symbols, etc to allow you to use whatever you have on your system but these feel like brittle solutions and the easiest one is to just build on an older/stable release. It isn't like it takes more than a second to make a VM or docker image anyway :-P.

Re: Baldur's Gate 3 Steam Deck – Native Version

#368
post #147

Earlier quoted context omitted.

I had that with MHW and I nailed it down to shader (fossilize-replay - https://github.com/ValveSoftware/Fossilize ). From my guess, Steam support Vulkan shader pre-compilation so that you don't have to wait in game (like the infamous 10 min Monster Hunter Wilds startup delay). They also seems to also be able to download the compilation cache from Steam if someone already have done the process on the same GPU + driver…

I have massive doubts about the "They also seems to also be able to download the compilation cache from Steam if someone already have done the process on the same GPU + driver version." This would imply that if I already calculated the shaders for the current game state than i could reuse them and not have to go through the whole compilation step (if no changes happen inbetween). Matter of fact, i have to recompile t…

That depends on game actually passing exactly the same parameters to shader compiler and your GPU driver actually building and using the cache.

What fossilize does is it generates data of all the parameters passed to shader compilation, and then can trigger "offline" compilation before you run the game.

Re: Baldur's Gate 3 Steam Deck – Native Version

#369
post #298

Earlier quoted context omitted.

Steam literally has a section called Hardware Requirements under every game.

As soon as what you have in your machine doesn’t literally match the stated system requirements, you’re on your own. It’s up to the user to research and understand which CPU or GPU is ”better” or ”worse” than the required one. These things are nontrivial when comparing between generations and across tiers, not to mention across different vendors. A knowledgeable user might be able to predict their performance reasona…

Most minimum/recommended game specs reference mainstream gaming CPU/GPUs, and most gamers know the strength of their own hardware relative to mainstream components.

If you're a very casual/young/inexperienced gamer then sure, you might have trouble comparing your own system with the min specs.

Re: Baldur's Gate 3 Steam Deck – Native Version

#370

It's worth noting that the native Linux version of games is often buggy and a far worse experience than the Windows version running on Proton. Valve itself is infamous for this: the Left 4 Dead 2 native game has multiple very annoying bugs that have been known for 15 years, and that Valve still hasn't fixed. Unfortunately, there is (another) bug that prevents the Windows version running on Proton from connecting to V…

Unless a studio is fully committed to proper Linux support (like, Feral-level), they might as well just optimize for Proton and call it a day

One of the reasons Proton has been so successful as a dev target is because the Windows API is not changing anymore and is thus stable.

The same, as I understand it, cannot be said about the Linux-native API. SteamOS may have stabilized it somewhat, but there's a reason why the readme on their site for this basically says "it may run on Linux proper, but we're not supporting it except on Steam Deck"

Post reply on HN