Linux Gaming

21984 readers

176 users here now

Discussions and news about gaming on the GNU/Linux family of operating systems (including the Steam Deck). Potentially a $HOME away from home for disgruntled /r/linux_gaming denizens of the redditarian demesne.

This page can be subscribed to via RSS.

Original /r/linux_gaming pengwing by uoou.

No memes/shitposts/low-effort posts, please.

Resources

WWW:

Discord:

IRC:

Gaming on Linux

Matrix:

Telegram:

Gaming on Linux

founded 2 years ago

MODERATORS

monolalia@lemmy.world

Why do game devs keep making horrible Linux Ports? (lemmy.world)

submitted 2 days ago by daggermoon@lemmy.world to c/linux_gaming@lemmy.world

50 comments fedilink hide all child comments

I'm asking because I just bought Cronos: The New Dawn on Steam because it has a native Linux port. To be fair, I would have bought it at some point anyway but I got excited when I saw it had a Linux port. The game is missing features that the Windows version has, It runs horribly at any setting other than very low. I think they only bothered testing for the SteamDeck. But if that's the case, why does it support FSR 4.0? To be fair, the Windows version doesn't run amazing either if you enable ray tracing but it still performs way better than the Linux port. Why do devs keep doing this? I've bought many Linux games that have problems that the Windows versions don't have. Why even make a port if you're not going to bother testing or optimizing it?

you are viewing a single comment's thread
view the rest of the comments

[–] BananaTrifleViolin@lemmy.world 19 points 2 days ago (2 children)

Also separate from my long response, thanks for sharing that link. Very interesting read and the GNOME window decoration issue is rediculous.

For me, I'm sorry to say, GNOME is the epitome of asshole design. This one of many examples of its rigid design philosophy having negative consequences for users and devs. And devs are protecting GNOME from its own users bad experiences because the user blames the game for not conforming, not the DE for being rediculous.

[–] Lemminary@lemmy.world 3 points 2 days ago (2 children)

It really does feel like Linux desktop environments like GNOME and Cinnamon got stuck in 2009 and never evolved past that. Even the community feels reluctant to adopt tried-and-true design elements of modern desktop environments, like removing the title bar so users can take advantage of that extra space at the top. "Wouldn't that cause issues?" Uh, no? It never has. It's time to innovate, please.

[–] corsicanguppy@lemmy.ca 2 points 13 hours ago* (last edited 13 hours ago) (1 children)

does feel like Linux desktop environments like GNOME and Cinnamon got stuck in 2009 and never evolved past that

If you think desktops are way not shiny enough, you should see this hammer I have. I've had it for decades. It's old. It's still got the dumb wooden/metal layout that's been common for a century or 5. It has no clock, no Ai, no Bluetooth. It's a fucking relic.

Piece of stale shit, if you ask me.

And don't get me started on this staedler pencil I have.

[–] Lemminary@lemmy.world 1 points 7 hours ago

I'm not sure what you mean. Removing title bars may look modern, but it's also completely functional. I'm not even advocating for a material theme or whatever, it's literally freeing up space.

[–] imecth@fedia.io 2 points 1 day ago (1 children)

You do know the reason GNOME is pushing CSDs is to get rid of titlebars right?

[–] Lemminary@lemmy.world -1 points 1 day ago (1 children)

No, I wouldn't know that because it's not implemented and I don't have a distro installed that uses it anymore.

[–] imecth@fedia.io 2 points 1 day ago

We're not talking about the same thing. GNOME did get rid of titlebars, most core applications use sidebars and the rest use headerbars - which are better integrated titlebars. I suggest reading the article.

[–] imecth@fedia.io 1 points 1 day ago

It's a none issue these days because toolkits and engines are gonna implement their own decorations anyways and for everyone else there's libdecor.