Baldur's Gate 3 Steam Deck – Native Version(larian.com) |
Baldur's Gate 3 Steam Deck – Native Version(larian.com) |
Kudos to Larian.
outstanding work by larien however, I just felt strange reading your comment which somehow implied that the translation is the reason for bad performance, when it is actually more performent then the original
Less see how those benchmarks compare, now that just like with netbooks, Microsoft is finally acknowledging they need to react.
The translation is the reason SteamDeck will suffer the same fate as OS/2, and netbooks, building castles on other companies kingdoms.
For that not to happen, the SteamDeck needs to be sold on its actual capabilities, not by pretending to be someone's else platform.
huh? but Steam Deck is just normal Arch Linux with x86_64 ~~aarch64~~?...
They don't want to deal with esoteric Linux bugs.
>>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.
Only half a step forward.
That sub is mostly pictures of "jUsT bOuGhT a StEaM DeCk", sob bait, random steam sales, and rarely ever anything useful related to the Deck itself.
Every now and then I go to check top posts from the past month to see if anyone has posted anything significant, like the DeckMate or EmuDeck or actual useful stuff. Inevitably, it's all standard reddit garbage.
The world is plenty big enough for all types of communities. Its okay for people to be proud of the things they lead, even if they aren't things that are interesting to you or me.
Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.Basically PROTON = ZERO BUCKS is the only sane way. I am playing proton titles: gacha games which are kind of free-to-play friendly, well... those without 'anti-non-steamdeck-elf/linux' software like ACE(cf WuWa). They have the windows whales to finance them already, and we are only penguins which dislike to be scammed.
But now elf/linux people will be able to buy this game with the legally required official support.
This game is really not my thing, but I'll go back to banging my head against the wall and throwing my keyboard thru the window, aka I am going back to play silk song natively on elf/linux available since day one of its release (well, this is a unity game, then ez).
For the first few months, act 3 (in the city) was legitimately hard to play. Performance, stability, visual glitches, all pervasive. But later patches did do a better job of improving those points.
Act 3's still the most intensive part of the game by far so on many setups it's still wise to at least crank down the crowd density, but it's come a long way since the launch version of the game.
It’s possible that some of the engine improvements could be easily back-ported to BG3. Or even just compiler improvements could be a little more oomph.
Edit:
> Our Proton version runs on the Steam Deck via the Proton compatibility layer, which requires extra CPU processing power. Running the game natively on the Steam Deck requires less CPU usage and memory consumption overall!
Workaround for a performance regression helps some but I suspect more has gone on.
Here's a review of Steam Deck performance from early 2024: https://steamdeckhq.com/game-reviews/baldurs-gate-3/
I'm assuming this is just an effort to slightly improve things.
I'm just happy the Steam Deck seems to be pushing devs to make sure their games run on low power hardware. Really any game should be able to run fine on the Steamdeck, there's no gameplay that isn't possible to run on the hardware. It's just the lack of engineering time spent on making sure the graphics have a proper low option.
Anyways, BG3 runs perfectly fine, natively, on my Ubuntu 25.04 RTX 4090 rig.
The window manager, package manager, etc are completely custom. The OS is a read only image based system.
Gaming on Linux is hard because there's not one Linux, there's tons of Linuses. What version of the glibc/libstdc++/mesa/xorg/wayland/kernel/drivers are you running?
The Linux ecosystem is fragmented in such a way that only open-source and an army of volunteers can really work around. It is really not binary-friendly at a fundamental, philosophical level.
(You're not going to get game companies to open-source their games, except as an exception, and after their economic life is finished)
The Steam Deck provides one well-known hardware and software platform that a vendor can reasonably target. Don't expect much more except by the most dedicated developer.
As of right now, proton and proton-ge both build in and require Steam Runtime Version 3 to run in. The steam client itself is running in a runtime, and I think it is the scout runtime, so LD_PRELOAD based. This means that steam has its own common platform to "deploy" against, and all Linux native games have a common platform to deploy against.
It used to be that games had to be compiled in a chroot for Steam runtime 1.0, but now with Steam runtime 3.0, developers are heavily recommended to build their game in a "OCI-based container framework"—so podman basically—and enable the Steam Runtime 3.0 on steam. I know that TF2 and Dota 2 use steam runtime 3.0, and apparently so does Retroarch. Of course, since there is a podman/docker image, you can also test existing games to see if they run in the runtime too.
You can find a lot of more information about the steam runtime 3.0 here: https://gitlab.steamos.cloud/steamrt/sniper/sdk
Valve has a gitlab with lots of great docs for developers who want to publish a linux native game.
I think all native linux games will run in the Scout 1.0 runtime by default
Edit: I will say that as an end-user, running an up-to-date Linux kernel and Mesa stack is important for gaming. I know some people who run Mint and are surprised that their Radeon RX 9060 runs like ass. As long as you aren't using a Debian based LTS distro, like mint or ubuntu lts, or you are running those distro but get a newer kernel, you should be fine. This matters less for older hardware, but having a newer kernel and especially a newer mesa version is important.
But sometimes something merely existing can prevent other things from flourishing, e.g. due to the mechanism of Schelling points:
How could you already have done this with the native linux build, which was just released today? I would think BG3 too long a game for that.
Or are you talking about playing the Windows build in Proton?
I feel like this describe how I feel about life in general. maybe we really are living in a simulation.
My question was about; do they enforce a device label?
That's irrelevant, because Proton is literally a Windows emulation layer, (the product of decades of cumulative work). "they" (Larian) didn't have to do anything for that.
Certainly Larian's effort for making a Steam Deck native version is commendable (I hear it was the result of one single employee's effort). Larian is a rare beacon in the video games industry biz for the amount of post-launch support and content they provide.
But my point remains: supporting Linux broadly is a far larger, and ultimately unreasonable, ask, than just supporting the Steam Deck.
To be fair, I've still spent a crazy amount of time with the Civilization games so let's say that was a partial success.
There are some hiccups at times, but it is acceptable, IMO.
You seem to comment with generalizations a lot.
Here is some data:
https://steamcommunity.com/stats/1086940/achievements
"The City Awaits (40.3%)"
So 59.7% of all players didn't make it to Act 3 on Steam, a bit under a "vast majority".
* Based on my experience
The alternative is using (what is effectively) a cross compiling toolchain to target Linux from itself! Or spin up an ancient Debian image (including ancient compiler) to build against ancient glibc.
It's hard to blame anyone for just using Proton, with the perma-stable Win32 API. No build containers, no chroot, no locking the build to Steam. Just the same build infra you already have.
One could argue that Proton is a kind of a container. It has a runtime system, filesystem, wine itself has several executables and interprocess communication, etc.
(Not saying mesa should be statically linked, but that we should be able to load and use it without libc)
WOTC were completely dysfunctional over the last few years and it nearly destroyed d&d.
- They tried to build their own bg3, except it was a VTT that they could fill with microtransactions, but they didn't know what VTTs needed to actually be used. They just thought: "Build something that we can nickle and dime all the users of"
- The new "backwards-compatible" edition that de jure isn't a new edition, but with the power creep is a de facto new edition.
- The OGL fiasco that shattered the community content creators who decided to attempt to make their own games "with blackjack and hookers". (e.g. daggerheart, dc20, draw steel, tales of the valiant, dragonbane, shadowdark, ) and bring their communities along to try the new games (including older offshoots like pathfinder 1e/2e, lancer, 13th age, etc...)
Imagine how much money they've had to pay their major community members (critical role, dimension 20, etc...) just to keep them playing the d&d branded games.
I would really love them to do a Fallout game. The original two games had a lot of properties to them that 3 and subsequent games just ignored or straight up went against, including NV. To me, as a fan who grew up with the first two, it's like a different game series.
I suspect not wanting to do BG4 is at the end of the day a negotiation tactic. There’s an amount of money and consideration that will make them put it back in the queue. But it’s likely at least five years out before they start on such a thing.
They’ll want to avoid the Torchlight trap, where the team got sick of doing Diablo clones and the company kind of cratered afterward.
BG4 will almost certainly happen, but by some other studio.
You can classify a vendor as a pain in your ass but if they get results, it’s time to look in the mirror and think about why you kept telling them to go right when they went left, and everybody loves the results.
Though it’s also true that a lot of key people have now left WotC and we are slowly working toward a situation where a Darrington Press game is more likely than a WotC game.
In terms of the wifi itself, I have two mesh routers in the house, one directly connected to the modem in the living room, and the other upstairs in my office, with the desktop plugged into it via ethernet. I'm lucky enough to be in an area with gigabit fiber, which made it seem worthwhile to invest in a good mesh setup, and I honestly might ended up with fairly low local latency mostly by accident from that. I've read some things that indicate that WiFi 7 might be a significant part of why this works well for me, but having never tried streaming games before having this setup, I don't have anything to compare it to.
On the software side of things, I mostly use the defaults that the AUR `sunshine` package comes preinstalled with for the server (although I'm not sure how much of that is tweaked from upstream). I don't have any ports exposed to the wider internet, and I have LAN encryption disabled, which likely reduces the overhead a bit. I'm not sure if it matters, but for the sake of completeness, but my GPU is a Radeon RX 6900 XT, and I'm running the standard Arch repo versions of of mesa, Plasma 6, and the `linux-zen` kernel (with Plasma configured to use Wayland rather than X11). On the client side, the Steam Deck is using Moonlight from the flatpak listed in the "Discover" app in desktop mode, with the resolution set to 1440p (since that what my monitor has, and I've found a lot of games lower the quality of the graphics if I lower the resolution to match my Steam Deck's native 800p) and the refresh rate set to 90 FPS, which the app then displays as converting to a bitrate of 49 Mbps. I have it set to fullscreen (since I don't really have any need to use the steam deck for other things when gaming, and it still does allow me to easily get back in to the local settings without much issue even with that set) and Vsync off, the boxes checked off for "Optimize game settings for streaming", "Capture system keyboard shortcuts", "Enable mouse control with gamepads...", "Enable HDR", and "Unlock bitrate limit" (the last of which presumably overrides the auto-computed bitrate mentioned above), as well as turning pretty much every audio setting I can off or at least to the lowest possible value since I'm pretty much always either watching TV or listening to music nowadays when playing. I left the video decoder and codecs as "automatic".
The only two things that ever seem to go wrong is that the Steam Deck sometimes seems to decide to render the on-screen keyboard below the streamed desktop rather than above it, and occasionally (maybe once every 10-12 hours of playing over several days?) the connection will start to degrade over the course of a minute or so and become unable to sustain the necessary bandwidth. The keyboard issue seems like it might be a bug in Moonlight, since I'm able to fix it by disconnecting and restarting the client itself, and the connection issue seems like it's either an issue with Sunshine or my network itself, since I can always fix it by simply disconnecting (without needing to restart Moonlight itself). The experience overall has been so good that I've almost completely stopped playing anything locally on the Deck itself (with the only exception being occasional emulation of Gameboy Color/Gameboy Advance games, which obvious don't require much in terms of hardware). I'm able to play games with much higher graphical settings than I could locally on the Deck, and the battery life is significantly improved (maybe around 6-8 hours of dedicated playing). It's such a smooth experience that I've been seriously considering upgrading to the Legion Go literally just to have a higher-res screen for this setup without having to change much (since SteamOS is supported for it nowadays; I don't have much interest in the Legion Go 2 with Windows, and the more powerful/efficient hardware wouldn't do much for me with my current setup).
[1]: I didn't have a ton of experience with mesh wifi honestly, but after some basic research I ended up buying of two of this mode (which seems to have a version of 6.1.0 from checking just now)l, and they seems to work reasonably well: TP-Link Deco BE25 Dual-Band BE5000 WiFi 7 Mesh Wi-Fi Router https://www.amazon.com/dp/B0DKVKLJX3
There is an arch x86-64-v3 repo, but I found it to be very far behind in terms of the most current packages, and I've experienced bugs with it.
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 settings.
What makes this story even better is how it actually came about - this wasn't initially a top-down corporate initiative, but rather a passion project from a single engineer who worked on it after hours. The fact that Larian immediately recognized the value and threw their full support behind it says everything about their culture.
Swen Vincke shared the backstory:
> The story of how this came to be really is one of true passion. The Steam Deck native build was initiated by a single engineer who really wanted a smoother version of the game on Steam Deck and so he started working on it after hours. When we tried it out, we were all surprised by how good it felt and so it didn't take much to convince us to put our shoulders behind it and get it released. It's this type of pure passion for their craft that makes me fall in love with my developers over and over again. Considering myself very lucky to have people like him on my team. Try it out!
https://x.com/LarAtLarian/status/1970526548592623969
That combination of individual passion and company willingness to back good ideas is what makes Larian special.
Just remember that stuff like red dead redemption ran on those things with all of 512 MB of unified memory. It ran and looked better than borderlands 4 does on current consoles.
Because they bought the game. After decades of PC gaming, it's totally absurd there is no system that tell you how bad or how well a game is going to play on your system. And if it's too difficult to make, how can we expect regular people to know themselves ?
Steam could probably build in a system to guess the performance if there was some benchmarking data, but game performance can change dramatically after release between updates to drives or the game itself.
The only thing I've seen which is close is Star Citizen's telemetry: https://robertsspaceindustries.com/en/telemetry
It's limited, but the limitations in a large part cancel out. It's still very capable.
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.
It's because most of those games don't have the graphics to justify choking.
On lower end hardware it's extremely easy to notice who actually programmed the game and who just used the Unity defaults.
Depends on what the game can be reasonably expected to run on. Most games don't even approximate what would be technically possible on today's hardware and waste your electricity on lazy coding instead. "15 years old hardware" is what was cutting edge when Crysis 2 and Skyrim came out, so that's not a good excuse in the majority of cases.
I game on 1080P and never have issues with any games I play, though I am on a 3080. It's definitely people trying to max out every setting for their 4K monitor that they overpaid for. I might be giving 2K monitors a try soon on the other hand.
15 years old? Have you seen many examples of this (I have not) or are you exaggerating to make a point?
Regardless, some very popular gaming hardware from 10-12 years ago is still in use and still very capable in modern games, so long as they allow tuning the graphics down. People running an i5 3570K and RX 480 at 1080p don't generally expect to get the imagery or frame rates of a modern gaming rig, but they are reasonable to expect roughly 60 fps with (for example) low textures and shadow detail, no reflections, static lighting, etc. Perhaps this is what you meant by "minimum settings", but:
While low-spec options like this have been the norm in 3D PC games practically forever, several very popular games released in the past 5 years have adopted anemic options menus that have negligible impact on performance at the low end. To someone with much experience tuning for older hardware, this is a striking and disappointing change. Especially now that gaming hardware upgrades are far more expensive than they were, and more people are struggling just to pay their living expenses.
The change is almost certainly unnecessary. It smells like the developers just aren't putting any effort into it anymore.
And it's not merely disappointing; it's also wasteful, both by pushing older hardware into the landfill and by denying opportunities to reduce power consumption.
> 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.
At this point game devs should just discontinue the native version if they aren't going to properly support it and just make sure the game runs flawlessly on Proton.
https://flightless.yobson.xyz/benchmark/10
https://flightless.yobson.xyz/benchmark/11
Roughly ~10% better FPS in Act 3 but the first benchmark average is pretty much the same.
You can download the native version on any Linux distro
https://old.reddit.com/r/linux_gaming/comments/1nokcej/laria...
I'm very grateful that they took the time to build a native Steam Deck release for the game, not really something I had ever expected. Hopefully with this I can actually jump in and enjoy the game!
This is the reason why I don't believe when people say that it runs great without trying it myself.
But if you survive the 12GB update process, I'm sure this is great news :) Maybe I'll finally have to make some time to play this game - bought it two years ago, but never ended up making time for it, despite having played Cyberpunk 2077 a time and a half, and most of Factorio: Space Age, since then.
This is a huge nitpick but I wish they'd just say "other Linux distros" instead of the "Linux platform". It's fine to pick and choose one (or a few) popular distro(s) to support, like SteamOS. It's not reasonable to expect support for all possible Linux software environments. It's already crazy that they support so many hardware combinations, even on just Windows.
"does not support" is not the same as "no", right? In theory it should be possible to run this build on other arm-based linux?
Does it get easier? Does anyone have any suggestions for coming to terms with the controller weirdness? I would much rather play BG3 on my Steam Deck than on my computer.
Occasionally I do still run things under Windows though like Cyberpunk 2077 as I got about 15 more frames under Windows which let me bump the graphics up a bit more.
Or Assassin's Creed Mirage which got me double the FPS somehow. Currently playing AssCree Shadows on Windows too as it just refuses to run at all via Proton. Other people seem to get it running fine so I dunno why I can't. Ah well.
I’ve since tried a number of highly touted recent CRPGs and RPGs… and gave up on all of them; BG3 really spoiled me I guess, but I’m also a pretty selective gamer.
The default campaigns in Neverwinter Nights are a mixed bag but the fanmade content is amazing.
The images themselves are fine, just the post's formatting squishes them.
I though the steam deck would be the reason why developper start building their game for linux, but it seems like it's a bigger issue than just making a "linux file". Once they have rewritten the code for the steam deck, what would prevent them to compile the game for Debian and other linux distributions ?
I really have no idea how much more work it is but assumed it would be straight forward.
I won't leave a bad review or whine on BG3, and my (otherwise very capable laptop) is just 6 years old with an Intel UHD 620 integrated GPU, and BG3 barely reaches the 10fps level on 1024x768 with lowest settings on everywhere. So it's not even 720p, and BG3 chokes a lot in this somewhat recent hardware.
I see BG3's graphics and while they are beautiful, they're nothing out of the ordinary in comparison to other games. That is, there are good games that could run very well in my laptop and which look good.
In sum, I see BG3 as being needlessly demanding, and pushes out a large sector of machines and potential buyers. I'd love to have an RTX-class GPU (and have the cash to afford it), but all I have it's a laptop whose GPU cannot be upgraded, and that is perfectly capable in all other areas.
Every time when I point out this limit in games, which I see as silly, I get flamed to death. People in the gaming communities are seemingly unable to understand why making extremely high minimum requirements is not a good sales strategy.
Games can look good with integrated GPUs. See the Wolfenstein games (id engine). Even more recent games like Generation Zero (Apex open world engine) can be run decently at lowest settings on my hardware. MGS5:PhantomPain also runs and looks very good. But no luck with BG3.
In a game which doesn't even look especially good, I see the very demanding hardware requirements as just a contribution to planned/artificial obsolescence.
(and yeah, I got downvoted as expected. This is getting old...)
I’ve seen the term across my life but I have never heard it spoken. I think how I imagine it and how it’s said are different - like I discovered from reading LOTR books and then watching the movies…
Is this a linux binary? Using wine directly linked under the hood?
Or did they actually build a native application with no translation layers, no matter how they're added?
Yes
https://steamdb.info/depot/2330359/
You can download the native version on any Linux distro https://old.reddit.com/r/linux_gaming/comments/1nokcej/laria...
Thanks to Larian for doing cross platform.
500 comments https://news.ycombinator.com/item?id=32471624
The syscall abi has been stable for decades, and any game that included glibc or compiled with musl keeps running just fine?
https://github.com/ValveSoftware/steam-runtime
https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/b...
The games by Loki Software are still running great for me. It's a matter of skill and discipline. SDL, OpenGL and alike are very stable.
The problems start when developers start to use lots of small third-party libraries and depend on particular versions of them, but IIRC on Windows it's also solved by simply shipping all the libs with the game.
https://www.forbes.com/sites/jasonevangelho/2024/08/21/linux...
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"
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 version. Since fewer Windows games use Vulkan this feature is often not used, but on Linux most games will run on Vulkan (esp. Proton games with dxvk) you may experience the process more often.
I have been having the issue with the system hanging up when steam is doing big writes. I had assumed it was due to something wrong with my drive and was contemplating reformatting it.
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 the shaders on every game start for every game, even if i restart the game just x times in a row.
For context: using linux/debian and basically running everything on vulcan
Disclaimer: I don’t even like macOS.
I wrote a user space memory reclaimer and have not got a lockup since. https://gist.github.com/EBADBEEF/f168458028f684a91148f4d3e79...
What am I missing here?
Putting up those guardrails temporarily hides big problems more often than it avoids needing to have them solved.
So for BG3, if you don't have 150Gb free on your disk, steam will download it on a different disk and then transfer it over, thrashing you disk.
It's bizarre, incredibly annoying, behaviour and I wish it would just ask so I'd know that was about to happen and just clean up some space. Or refuse the upgrade.
But steam want to force upgrades on users before you can play anything, which for single player games is incredibly frustrating. I get why they do it, but it's another one of those things where you feel like you aren't in control of the thing you paid a lot of money for.
You could do that in the past and I did occasionally for single player games because my internet connection wasn't the best and I did not want to waste the little time I could allocate for gaming.
I am amazed this game is even playable on the steam deck. Was trying to find an excuse to play it after cyberpunk. I guess this one it is…
Yeah, I know most people will say the Deck is already too slow for 800p, so why would it pull 1080p well?
I have two decks, one's got Deck HD, the other doesn't. I render the Deck HD one at 540 native and upscale 2x with FSR. It looks way better than the stock display one and runs better as well. Similar with HZD and other highly demanding games.
That said, 99% of my time on the Deck is spent playing retro games. Does that need 1080p? No. Can it use it? Yes, very much so.
I never pick up the original deck anymore - the Deck HD modded one is just better.
- https://www.lenovo.com/us/en/p/handheld/legion-go/len106g000...
- https://rog.asus.com/gaming-handhelds-group/
Honestly, I think a gaming laptop and a controller makes more sense for most things, if you don't need that little bit of increased portability.
I used to be a great fan of Prey Project, but I don't think it's installable on the Steam Deck without leaving Steam mode.
I'm not sure if I can recall any tips other than just keep at it and it'll eventually become muscle memory. I don't think it's as good as KB+M but it wasn't something that was bugging me once we got significantly into the game. YMMV.
To me, the modding ecosystem is probably one of the two most important things about this game (the other being that Larian seems to be pretty awesome as far as studios go nowadays, with their CEO taking a firm stance against "crunch" to get games out and in favor of the model of offline games that don't require paid DLC or microtransactions, as well as their continued support of the modding ecosystem itself). Long before I ever considered writing any mods myself, I started referring to BG3 as similar to Skyrim in that the mods will likely keep things fresh long after new official content stops coming out. I still think this is true, but I also keep being surprised just how much work they're continuing to put into the game even with new content presumably finally having come to an end.
Announcing official Linux support would also require testing on Intel and Nvidia GPUs, as well as other types of AMD GPUs, which would probably take much more time and effort than testing for a device with effectively two hardware revisions you need to test for. I don't think they want the support burden, and I don't disagree with them having had to debug obscure Linux GPU issues myself.
Despite all this I think it’s still a move in the right direction.
On the other hand, that stack can only contain so much, and a lot of Linux bugs involve sound subsystems, GPUs, and compositors/X11/window manager configuration issues. You can't quite target the Linux runtime and assume everything will just work, but at least you don't need to target specific versions of glibc and libxml2 anymore.
You can install Steam on Debian.
I think the value here is that with Steam being the "approved launcher" you offload a lot of "distro weirdness" over to Valve. The value of a standalone build seems fairly low for most game devs.
1000x this.
When I grab the deck it's downtime mode for me now, keyboard/mouse time is work or side-project mode.
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.
The most comfortable and consistent gaming experience is still a regular stationary PC. But if you really want to play Civ5 on a train then sure the Steamdeck is there for you. I just never felt the need to game something that bad.
That would be playing console on an 80 inch screen from a couch.
I would have gotten a mini PC, but strangely enough the Ally was the cheapest steamOS-compatible option I could find.
My current obsession is Satisfactory.
Is there any data to support this? IME most PC gamers I know don't give a shit about telemetry. They are stock Windows and Android users, love Google products, etc.
They only care whatsoever when it comes to adblocking, because they don't want to watch ads.
(I'm also in the US)
There's also been persistent speculation about whether Valve would take on the burden of releasing SteamOS as a general distribution anyone can install on their own hardware (which I think is unlikely), which could in turn affect how Larian has to treat this port even if that is just communicating what it is and isn't.
I've heard about multiple games that where steamdeck verified but the performance choppy. If it can't hold a steady 30fps, a game shouldn't be steamdeck verified in my opinion.
1. Enroll is the discount program by running steam hardware survey. Steam holds onto your system specs.
2. Steam offers discounts for games that have insufficient benchmarks for your rough system.
3. For these games, steam collects performance data (either 5 minutes of benchmark before, during the game, first run, or maybe when the PC is idle (screensaver mode)).
There's all sorts of way they could do it. I'm guessing a large portion of people would be fine with a "Folding at home" style system, that just runs benchmarks for screensavers (with some coupons or whatever granted).
I think you kinda hit the nail on the head, but I believe there is an extra dimension to this: desire.
For BG3, it looked fun and I had good memories of BG2 so I was interested in playing it. After tuning the settings a bunch and not being able to get a consistent framerate / not have micro-freezing, I just said "oh well, I'll play it on some other platform in the future." I cared about BG3, but not that much.
This is in contrast to Elden Ring Nightreign, which also had issues. I was able to get it to a somewhat stable 30FPS and celebrated that success before dumping 100+ hours into the game. Why? Well, because I love FromSoft games! I really really really wanted to play the game and was willing to put up with a somewhat subpar experience in order to get it. BG3, among other games, is just not that exciting for me personally so my tolerance of technical hitches is very different.
... which brings us right back to this native release. Hopefully the improvements we see are enough to get me over that "hill" and actually enjoying the game. I have the update queued on my deck now so I can try it out after work.
To be noted: the main appeal of Neverwinter Nights 1 is the player created content. In particular the main campaign of NWN1 is pretty "meh" and is better thought as a showcase of what's possible with the scenario toolkit (the expansion - what we call now DLC - are better in that regard though). The creativity deployed by some creator is quite astonishing; shootout to the Bastard of Kosigan (James Bond-esque adventures in a kinda alternate historical France), and HeX Coda (magipunk setting where you fight as a champion of open-source magick against corporate wizards).
But as somenameforme noted, you have to content with early 2000 production value .
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/...
https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/b...
I hope they'll drop 32-bit support in the runtime with the next major version. More and more distributions are dropping it or are thinking about it. Any new game should really use 64.
This is absolutely unacceptable and if this happens with nearly every big release, then that also speaks badly of the engine itself. Similarly to how languages like C++ are very powerful and can be used to great effect... and people almost inevitably still write code that has memory safety issues. That comparison should make a few ears perk up, my point is that fewer developers should use Unreal Engine 5 if they can't use it well (same as with the languages).
Frankly, I place more trust in studios that have their own engines or use literally anything other than UE5, like what happened to KDC:2, a modern game that looks good and runs great across a wide variety of hardware. Or how they fixed Cyberpunk 2077, it took a while to get there but now both the visuals and performance are quite good across the board.
This has been so comfortable that this helped me ignore the pain in my arm after a fracture/surgery this year.
Yes it can't play Cyberpunk but it'll handle native Android games, classic emulation, and any cloud streaming very well. You can also install moonlight on it and stream full fat desktop games too.
I'd love to see a steamdeck lite, with a similar size and weight to the switch. But still with the rounded hand grips of the steamdeck. The deck as it is feels like a HN designed product with way too much stuff jammed in it with no regard to size and weight. The trackpads are cool for desktop mode but the space taken up for something so rarely used isn't worth it.
In hindsight, I really didn't need Windows, but I was impatient.
That said, bg3 does run on 10-year old hardware. The minimum requirements lists a gtx 970, released 2014. Which, despite its age, is still 6x faster than your integrated graphics.
I am not trying to victim blame or anything, I just can’t imagine a situation where I could forget something so big.
[1]: https://baldursgate3.game/news/room-temperature-fix-33-now-l...
BG3 already ran well enough on Linux, so I imagine this will only make it run better, official support or not.
A knowledgeable user might be able to predict their performance reasonably well, based on publicly available benchmark databases, but you still can’t really get a good estimate FPS unless you find someone with exactly your hardware setup who benchmarked the game (and is willing to share).
If you're a very casual/young/inexperienced gamer then sure, you might have trouble comparing your own system with the min specs.
It’s a shame that large companies like EA/Bethesda/Valve/etc don’t do more to fight against it, instead of cowering and leaving indie devs that are barely surviving to fend this off.
Unfortunately, singling out any individual developer, even for praise, can attract unwanted negative attention online. By acknowledging the passion and the work without naming the person, Swen gives them full credit internally while shielding them from becoming a public target.
This doesn't even necessarily have to be intentional harassment, but if this engineer is now the "SteamDeck guy" at Larian, their social media might get flooded by people who mistake their personal social media accounts for a support ticket.
I'm sure the engineer has the option to self-identify if they wish, but this approach feels like a sign of good and thoughtful leadership.
Seems enormously more likely to be the all to familiar story in the games industry of not providing credit to individual devs. Something that goes back to the earliest days of Atari.
Because these guys and gals are not famous enough to warrant large coverage, and because the phenomenon is unfortunately so widespread that noone is going to cover every case.
https://endofaspecies.com/oped/the-harassment-of-game-develo...
https://www.bbc.com/news/articles/cx2621gzvkdo
https://old.reddit.com/r/gamedev/comments/zoe13c/passionate_...
https://www.gameshub.com/news/news/video-games-developers-gd...
https://www.xfire.com/authorities-investigating-death-threat...
I can't think of specific names anymore since it's been a while since I have played it, but a lot of the developers for World of Warcraft used to be and likely still are active on Twitter. For a lot of them, the community knew fairly well which features of the game or which class they were responsible for. When I used to look at the replies to some of their Tweets (even ones completely unrelated to WoW), they were often full of complaints about their area of perceived responsibility.
I fully understand every engineer who just wants to put their head down and work on their stuff they're passionate about without having to also be public-facing. Even in a small company like mine, some of our devs constantly complain that some customers know that they are responsible for certain features of our product and email them directly rather than going through the proper support channels.
Your point about the games industry often struggling with providing proper credit to devs is well taken - it's absolutely an issue. But in this case, Vincke did actually do that, in a way. He could've just kept quiet and let the playerbase think it was a company effort, but instead he publicly highlighted and recognized the passion and work of one of their engineers (even though anonymously). That engineer can look at the countless positive replies to that post and get the nice fuzzy feeling without getting dragged into the spotlight.
The real reason many of these games run like shit is over reliance on real time lighting systems. RT lights are easy. It's easy to throw a bunch of artists into a box and hope for the best. A complete idiot can make a scene mostly look good without much thinking. Baked lights require a lot of anticipation and planning. It impacts iteration time, etc. The tradeoff being that this is orders of magnitude more performant than RT lights. Imagine watching Toy Story after the offline render vs attempting to do it live. This is literally the same scaling problem.
https://dev.epicgames.com/documentation/en-us/unreal-engine/...
If you want performance on everyday hardware, there is no way (and I'd say this holds true for any engine, not just UE5!) that you dig down into the engine an the libraries and invest the money in testing to tune the performance appropriately.
And don’t get me wrong, those features are great, but they’re not intended for low-end hardware or where fps is a priority.
This isn't a case of "these developers are lazy", UE5 issues are the case of "every single UE5 released game has shader stutter issues on PC". That's an issue with engine architecture and its APIs, not an individual thing.
Just because an engine offers you a way to shoot yourself in the foot with a sawn off shotgun, you can't blame the engine maker when you do shoot yourself in the foot with a sawn off shotgun and end up with a bleeding ugly stump.
The thing is, of course game studios will go for "we want to use ALLLLLL the newest features, we want to show off with Nanite and god knows what else". Who wouldn't? But game studios aren't willing to put in the effort surrounding such an implementation to properly tune it.
And it's not just tuning engine components for what it's worth - often enough the culprit ends up being ridiculously oversized textures, there's nothing else that could cause dozens of gigabytes worth of patches [1], and it's not a new complaint either [2].
[1] https://www.neogaf.com/threads/days-gone-whats-up-with-the-r...
[2] https://forums.guru3d.com/threads/are-game-patch-sizes-becom...
One of the reasons that a lot of studios struggle with bad performance on UE5, is because a lot of studios, fired their most experienced devs and hired bunch of cheaper new programmers, because they bought into the whole make game with blueprints idea. I have several friends (I know just one datapoint ), that were in games industry from 6 to 12 years that got fired, just for the studio to replace them with cheaper more inexperienced devs.
Baicly UE5 overpromised how easy it was. You still get some great working games that use UE5, but this are from studios that have experienced devs.
Another option is to dynamically link against an old glibc version, the Zig toolchain makes that easy also for C/C++ projects.
There are many issues with libraries breaking backwards compatibility on Linux (like pretty much all GUI ones) but glibc, X11, OpenGL (and to some extent SDL - it used to not be like that, but in recent years they made "SDL1->SDL2" wrappers and there is or will be a "SDL2->SDL3" wrapper too) are fine. I'm not sure about Vulkan but i'd guess that is fine too.
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 supposed to be ABI backward compatible anyway.
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.
I wanted to port my semi-minimal 3D ECS game engine ~(10k lines) to a minimal distro, so I decided on Alpine after figuring Arch is actually very bloated on comparison.
I had to recompile even the single-executable command line prebuild system (premake5) for musl. Musl is a more minimal version of libc.
Got it to work fine after that, building a few components from source and getting a few like sdl from the distribution's repos. (also had to of course install relevant driver bits to get opengl working as the distro is truly minimal)
https://www.techpowerup.com/239687/latest-steam-client-beta-...
Shader precompilation is a standard thing to do now - consoles mostly ship precompiled shaders for their GPU + driver combo, Steam Deck will also download precompiled shader for its Linux + AMD + driver version combo.
The infrastructure for that Steam side is there and is in active use.
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.
This just , from a technical stance, doesnt make sense to me.
As another commenter to my statement wrote, it might be to make sure enaugh people have the same result on my HW setup in order to make sure its not abused for maleware. That makes sense to me tho i still dont get why there is not at least some local steam client caching.
And while as mentioned this might not work with every game - well it works with none. Im talking about a quite big set of games. So maybe im just VERY unlucky and ALL games i play have dynamic params which as you mention would result in recompilations every time - will have to look if i can approve this somehow.
Alternativly, which is why i mentioned using debian, its a linux issue of some sort (just a guess).
Thanks for explaination tho
What Steam does is to skip the compilation and download it from a cdn.
In your case something is not letting the driver cache the compilation.
I don't think I ever found more documents on this feature. I assume it might need lots of users with matching result to ensure that bad actor can't upload malicious shader.
Tho i would expect (naive me) that the shaders at least might be cached locally - which is not the case since as i mentioned in my comment have to recompile them for every game every time i start.
It is like judging someone for taking an advantage of the new CPU instructions that accelerate processing because general instructions are already good enough.
I spent like 98% of my playtime on the original in handheld. That has switched completely. It’s not just the size but especially the weight I think.
The Switch 2 and the Steam Deck are hugely different machines, despite sharing a form factor.
Obviously SD can be more than just "handheld console", but a lot of people won't need that.
Thanks for the hint tho, if i should find the time to investigate that further this will definatly safe me some time on searching the cause-
What you can’t do is hit compile out of the box and expect it to work well on those low-end platforms, because it will try to use all the high-end features if it thinks it’s allowed to.
I don’t think it exactly overpromises how easy it is, but unlike a lot of software it has a learning curve that seems gentle at first and then exponentially increases. It’s high-end AAA-grade development software aimed at professionals, it expects you to know what you’re doing.
i guess that's that then!
I mostly use SD to stream from my main rig, so i can always have >60fps on my SD.
Also, Valve has recently insituted changes about how native titles work forcing existing native titles onto the scout 1.0 runtime and giving developers the ability to pick newer stable targets.
https://store.steampowered.com/news/collection/steam/?emclan...
> Native titles will execute in 'Steam for Linux runtime 1.0 (scout)' by default, instead of the legacy runtime environment. This behavior is consistent with Steam Deck and promotes better compatibility across all Linux desktop distributions. Note that this new feature can be turned off globally with "-compat-force-slr off" on the Steam client command line.
Its also the case that the original version of this that was bouncing around in the 2010s was more of a gaint shell script hack and it was possible for games to depend upon the host system in way which could break over time. Today it is utilising stuff in the flatpak ecosystem:
https://ftp.belnet.be/mirror/FOSDEM/video/2020/UD2.208/conta...
Sometimes if there are issues with the native linux release you can quickly swap over to the windows/proton version and see if that fixes issues.
Valve are absolute heroes in trying to create stable targets for linux gaming whether that be running windows games via proton or having a stable container target for native support.
I haven't had to boot into windows for nearly a year at this point and yet still playing new games on release without much issue (occasionally had to force to use a newer version of proton).
The only games I cannot run are competitive multiplayer games that do intrusive kernel level anti-cheat, but fortunately I don't play those games. https://areweanticheatyet.com/
That's kind of a twisted interpretation of events. It was coloured by one incel who though he owned the developer of a game and a whole lot of incels who sympathized because they too were owed a vagina by the ones who controlled them. Now it's spread to broader issues and higher levels of politics and is still going.
But it was too close of a tangent towards criticism of establishment journalism in general, so of course establishment journalism countered back with the only weapon it has, and suddenly the vast majority of people forgot any of it had to do with reviewing and promoting good indie video games.
People who make indie games are not losers. People who want good games to be promoted are not losers. It is an art. It's not for everyone. People who just want to play the latest AAA sequel can stick to those. But if you've ever tried a niche indie game and been more impressed than you expected, you know it's art, and you'd want other people discovering and promoting the good ones, and talking about what makes them special.
Every single one of them later turned out to be a sexual predator. This is now known as the "softboi" or "male feminist". This kind of person is still out there and is dangerous as ever, so it's important to keep an eye out.
(None of these people were in tech; instead all my tech coworkers who were men and lived in SF also heard "we need to respect women", but being kind of autistic engineers took it too literally and didn't seem to know any women, so they seemed to think the right thing to do was go out and find a woman and literally just start respecting them. This didn't work out for them and they mostly ended up getting scammed by scammers who happened to be women.)
A game reviewer should not be in sexual relationships with people selling games that get reviewed. I think anybody not ideologically captured would agree.
I also find it tasteless to use the same rhetoric here as it was used back then to slander someone into suicide.
I don't think you need a case quite this specific because of the following:
> then attacked for issues with the company beyond their purview
Ultimately, whether an employee is praised or not is completely irrelevant to the nutjobs taking their anger out on them because of something their employer did.
My initial skepticism was based in the voluminous amount of false allegations of harassment and misportrayal of valid criticism as harassment that happened at one point several years ago in the games industry.
Disagree however about the value credit - personal credit has concrete value (career wise, status wise etc), warm and fuzzy feelings less so. Right now we can only guess whether the dev had a say in the matter.
The engineer can still leverage this (LinkedIn, internal promotions, industry networking) without being forced into a public-facing role they might not want. When they're interviewing or networking, they can point to Vincke's public acknowledgment and say "that was my project" in contexts where it's professionally relevant, without having their personal social media permanently associated with it.
Considering Vincke was impressed enough to publicly acknowledge this individual's passion and initiative, there's no doubt in my mind that this engineer could get named credit or something that would acknowledge their role in the project if they wanted it.
But to go a bit meta: I think it's strange that we are discussing this in the context of a CEO publicly acknowledging one of their engineers (even if anonymously). Vincke is, at least in the context of the broader industry, going above and beyond. I doubt you'd see Ubisoft, EA, or Blizzard publicly acknowledging a single engineer's after-hours passion project in this way.
Feels a bit like misdirected energy, I guess? Why are we debating about the nuances of named vs anonymous credit and recognition when industry leaders don't give any?
It's like calling someone out for only tipping 10% while ignoring the guy in the top hat who's tipping 0. If you want gaming companies to get better about giving credit and recognition, you should support the companies that are at least moving in the right direction. I know it's easy to be cynical, but don't let perfect be the enemy of good.
I very strongly agree all creative workers should receive fair recognition (and compensation) for their work. I disagree with directionality as a moral framework. Doing something similar to the right thing is not necessarily doing the right thing. In this case my immediate assumption would be that the CEO is boasting about their anonymous hardworking impassioned employees as a way of 'glazing' the company, rather than shielding them from public criticism. It's impossible to know, but CEOs are not generally known to be good and ethical people. Larian may well be exceptional in this regard, but giving the benefit of the doubt to CEOs in general is a poor heuristic.
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.
The 360/PS3 was a huge jump forward but very limited by today’s standards. RDR was one of the better looking games of the generation but could not maintain a steady 30fps at 1080p/i (and I’m not sure it was even true 1080).
The PC version came later, had higher resolution textures and other graphical improvements so it compares more favourably to modern games when you play it today. It still had problems running on all but the highest-end PCs of the time.
Of course even low-end PCs can run it without breaking a sweat, because they’ve become much more powerful.
The performance problems in modern games are often not caused by fillrate-vs-resolution bottlenecks though, but by poor engine architecture decisions (triggering shader recompilations in the hot path).
But I’m confused about why you think fill rate isn’t an issue? If you are now upgrading from 1080p to 4K your GPU needs at the very least 4x the pixel pushing power and even then that’s only to maintain the same detail; you bought a 4K screen for more detail.
Maybe that is even related to it's good performance on consoles back then: Rockstar invested a lot of development time and sacrificed portability for performance. Basically the opposite of what modern games achieve with unreal 5.
The game felt like it had significant input lag, and at 720p with upscaling text becomes very hard to read. The game's visual style of "glitch" effects also translates badly with upscaling and I really had a tough time actually understanding what I'm looking at on the screen.
Perhaps the situation is better on OLED.
It's the #10 top most played game on Steam Deck.
The game on new machines is quite impressive, quite unlike anything else made.
Wouldn't that depend heavily on the game and developer in question? The Switch 2 has more than sufficient hardware to compete, with a particularly beefy GPU for a handheld.
I'd be more ready to blame the game and developer in question than this console, unless there are a lot of examples from capable developers performing measurably worse.
On Switch, I had to expensively rebuy games at high prices, which then ran poorly and didn't support any kind of settings to try to fix the situation.
On the Deck I get all my desktop Steam library and I can change game settings until they run as I like (within reason).
I don't see how those two are comparable purchases - I either get a console which runs poorly and demands 40$ for games that are like 5$ on Steam... or a console that already supports my existing library AND on top of that allows me to stream games from main PC at full detail and framerate.
Leaves the question who is to blame completely out.
And as a consumer I couldn't care less why it doesn't work. I paid for it, it doesn't work: I am not recommending it.
Easy as that. I don't have to write thesis about such stuff.
You're probably right though, if it's any consolation.
It doesn't change the reality though, that currently many of the cross platform titles don't work well on the Switch 2.
Because this is can be easily dealt with via upscaling or buying a more expensive GPU, but fixing shader recompilation in the hot path requires a complete engine redesign.
You don’t need a full engine redesign. UE5 provides tools for PSO bundling and also pre-caching, but you need to use them.
Also good material design and structure helps reduce the number of PSOs needed but again, you need knowledge of how the engine’s materials system works.
If you are interested, this video explains some of the solutions. https://youtube.com/watch?v=i35yf-wh3Bs
Presumably people do this because they hate money; as you say, it's much harder to make the pixels just slightly more crisp and you'll pay dearly for the privilege.