You must log in or # to comment.
So, it runs on Steam Deck natively and yet doesnt support Linux? How does that work?
So, it runs on Steam Deck natively and yet doesnt support Linux? How does that work?
Probably that they officially support Steam Deck and not other hardware. For example don’t expect them to fix bugs that only occur on NVidia drivers.
Steam on Linux provides a fixed target set of libraries because it’s kind of hard to release native games on Linux (you have to include a crapload of libraries you expect to be installed otherwise, which Steam solves).
Larian is essentially styling now. Even Valve doesn’t release native ports anymore and went as far as removing some in favour of Proton versions.
Even Valve doesn’t release native ports anymore
That’s just not true. Deadlock’s development only happens on Windows but other new releases like the HL1 remaster have been ported to Linux (while at the same time dropping Mac support).
If CS2 is any indication, Deadlock will launch on Linux with its 1.0 release.
HL: Alyx had a native port, it’s Proton only now. Is CS2 or Deadlock native or Proton?
I’m not aware of any new Valve HL1 remasters and Black Mesa was an indie effort. Similarly TF2 is being ported to ARM Macs by indie teams now that source code is available and Valve couldn’t be bothered.
HL: Alyx had a native port, its Proton only now.
https://steamdb.info/app/546560/ says otherwise. Also, Alyx A) predates Steam Deck by several years and B) Steam Deck is not a VR platform. Citing a game that predates Steam Deck as proof that “Valve doesn’t release native ports anymore” is a stretch.
Is CS2 or Deadlock native or Proton?
I already stated that CS2 is native and Deadlock 1.0 may be as well, should they follow the example set by CS2. You literally replied to a comment stating that.
I’m not aware of any new Valve HL1 remasters
Well, that’s on you. https://www.half-life.com/halflife/25th exists nonetheless: “Now Verified on the Steam Deck (and our native Linux runtime has been set as the default)”
https://steamdb.info/app/546560/ says otherwise. Also, Alyx A) predates Steam Deck by several years and B) Steam Deck is not a VR platform. Citing a game that predates Steam Deck as proof that “Valve doesn’t release native ports anymore” is a stretch.
Alyx had a native port. It doesn’t anymore as shown on Steam DB. This is because since Proton nobody cares. Not a great long term solution.
I already stated that CS2 is native and Deadlock 1.0 may be as well, should they follow the example set by CS2. You literally replied to a comment stating that.
CS2 is just CS which had a native port. I won’t pat Valve on head that they aren’t doing more games dirty like they did with Alyx. Won’t speak about Deadlock until it releases, we’ll see.
Well, that’s on you. https://www.half-life.com/halflife/25th exists nonetheless: “Now Verified on the Steam Deck (and our native Linux runtime has been set as the default)”
Completely missed it, very nice, thanks. There’s even a Mac port, will check later.
Larian is a good company overall but this is plain stupid
And why do we only get this 2years after the game released ? It’s one of the most played games on deck !
Because they’re done with the game and have moved onto their next thing, they explain this is literally one dudes passion project. That’s why there’s no Linux support, it’s one dude who wanted to play the game on his deck better. Sucks, but that’s the way it is.
the steam deck didn’t exist when the game was in development. industry is slow to adopt without strong monetary incentive. the fact that a large studio is acknowledging the deck as a viable option means we should start seeing optimizations like this in the wider industry.
Maybe because everyone keeps repeating the lie that Proton is the perfect Linux game platform.
I don’t think anyone is claiming that Proton is perfect, but it certainly beats not being able to play most new-ish games. Which was the situation on Linux prior to Proton.
it certainly beats not being able to play most new-ish games. Which was the situation on Linux prior to Proton.
That’s not the point of my comment. My comment is about clueless people claiming that Proton is superior to proper ports running natively on Steam Linux Runtime 3.0. Larian are now stating the opposite and as you can see from downvotes and Thaurin’s commet that people still think that.
Not perfect, but close to it.
Not perfect, but close to it.
“Running the game natively on the Steam Deck requires less CPU usage and memory consumption overall!”
Larian says the opposite and they know much better than randos on some internet forum. Proton is fine to bridge the gap especially for unmaintained games but proper native version are the clear superior option.
It depends. If there is enough CPU and memory headroom, it’ll be fine. Some games run better, some same, some worse.
If there is enough CPU and memory headroom, it’ll be fine
Steam Deck is a handheld platform. Anything that wastes CPU power results in shorter lasting battery. Proper native ports are always superior.
Steam deck is a closed ecosystem so it is likely tied to the file system and bundled libraries.
It would likely take a little work to get it working on other distros, but the underlying binary is now going to be elf and use the correct system calls
Edit:
Closed ecosystem is not the right word. Probably known system is a better way of saying it
Steam deck is a closed ecosystem so it is likely tied to the file system and bundled libraries.
It would likely take a little work to get it working on other distros, but the underlying binary is now going to be elf and use the correct system calls
Steam Linux Runtimes (currently at version 3.0) are shipped with all Linux versions of Steam. SLR 3.0 is leveraging Bubblewrap, also used by Flatpak, for a containerized approach to libraries. Games are not supposed to talk to SteamOS libraries directly. SteamOS itself is not a stable development target by design.
Works well on my little bazzite machine. Loads hella fast now.
Loads hella fast now.
Of course. Running games on Proton means that all required Windows DLLs and their reimplementations need to be loaded into memory first.
