this post was submitted on 12 Jan 2026
324 points (99.4% liked)

Linux Gaming

24079 readers
62 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:

Matrix:

Telegram:

founded 2 years ago
MODERATORS
top 33 comments
sorted by: hot top controversial new old
[–] mech@feddit.org 73 points 3 weeks ago (1 children)

When will they finally add Copilot?

[–] TrumpetX@programming.dev 27 points 3 weeks ago (1 children)

Upvote or downvote, I cannot decide. I'm both laughing and terrified it could happen.

[–] mech@feddit.org 8 points 3 weeks ago

Once Microsoft has finished the transition of Windows into an Edge launcher with a Copilot backend...

[–] inzen@lemmy.world 40 points 3 weeks ago (3 children)

I wonder if at some point Wine on Linux will become better than Windows itself.

[–] Igilq@szmer.info 29 points 3 weeks ago (3 children)

For most stuff wine is working better than on Windows. Thats why people actually import wine drivers to their real Windows install

[–] ArsonButCute@lemmy.dbzer0.com 6 points 3 weeks ago (1 children)

Yo what people do that? Gnarly.

[–] Die4Ever@retrolemmy.com 12 points 3 weeks ago* (last edited 3 weeks ago)

for Deus Ex Randomizer, we include the DXVK DLLs as part of the Windows installation automatically, because it runs better and smoother and with less issues

(we run vulkaninfo to check compatibility first, we check support for VK_KHR_maintenance6 or Vulkan 1.4 or newer, otherwise you don't get DXVK)

https://github.com/Die4Ever/deus-ex-randomizer/blob/master/src/installer/Install/init.py#L123-L151

[–] inzen@lemmy.world 6 points 3 weeks ago

I did not know this was a thing 🤯

[–] KneeTitts@lemmy.world 3 points 3 weeks ago (1 children)

For most stuff wine is working better than on Windows

So why dont any of my apps work then? Im super happy gaming is about 85% working, but in the apps space its got to be less that 40%

[–] Wispy2891@lemmy.world 2 points 3 weeks ago

The funding (valve paying crossover devs) has the focus on games, almost nobody is purchasing crossover for apps

[–] Wispy2891@lemmy.world 10 points 3 weeks ago (2 children)

For games it's already better, I get a few extra fps on my low-end laptop with integrated graphics and the best part is that I don't need to worry about games leaving traces/trash in the system as they are placed in individual prefixes

[–] orochi02@feddit.org 1 points 3 weeks ago

Except cassette beasts (for me) 😔

Literally saves are outside the Prefix for some reason. Apparently has to do with a heroic flatpak quirk 😒

[–] markovs_gun@lemmy.world 1 points 3 weeks ago

I have an old mid range gaming rig and I also get improved performance on linux mint with steam proton

[–] schtobia@augsburg.social 7 points 3 weeks ago (2 children)
[–] inzen@lemmy.world 6 points 3 weeks ago (2 children)

Oh wow, all the legacy software would be stuck on old windows or have to move to linux. If I got that right.

[–] Damage@feddit.it 1 points 3 weeks ago

They could implement a compatibility layer themselves, Apple managed to keep compatibility moving from PPC to x86 and then to ARM

[–] ashleythorne@lemmy.world 3 points 3 weeks ago (1 children)

There was an update to that post, where the author said it was a "misinterpretation" and that it was just a research project.

[–] schtobia@augsburg.social 1 points 3 weeks ago (1 children)

@ashleythorne true! But the Win32 ABI was the "holy grail" of Microsoft. You can run a Win95 application written under Borland C++ today! That they even _considering_ of breaking that, would be *unthinkable* a few years ago.

[–] jj4211@lemmy.world 1 points 3 weeks ago

There was some experiment they did in the mid 2000a that was also going to be completely incompatible. It went nowhere.

[–] TrickDacy@lemmy.world 21 points 3 weeks ago (2 children)

When does proton start pulling it?

[–] Anafabula@discuss.tchncs.de 17 points 3 weeks ago

Wine 10 to Proton 10 beta took four months

[–] mlg@lemmy.world 7 points 3 weeks ago (1 children)

I know Proton-GE usually takes a week or two.

[–] mybuttnolie@sopuli.xyz 3 points 3 weeks ago (1 children)

if proton is a few months behind wine in big updates, does proton-ge update faster? or is it a week or to behind proton

[–] mlg@lemmy.world 4 points 3 weeks ago

Proton-GE is essentially bleeding edge with all of its dependencies and upstream set to latest, so it gets updated constantly as a rolling release.

Valve waits until the next version has been well tested before bumping it in proton experimental, and then eventually the default release.

[–] iopq@lemmy.world 2 points 3 weeks ago

Excited to try ntsync and other improvements.

[–] cybernihongo@reddthat.com 1 points 3 weeks ago

Should I switch from Wine Staging to stable?

[–] bufalo1973@piefed.social 1 points 3 weeks ago (1 children)
[–] Buddahriffic@lemmy.world 5 points 3 weeks ago (2 children)

Running another uarch is a whole new level of complexity vs just running on a different OS but with the same uarch, especially if concurrency is involved because translating from one instruction set to another can break atomicity assumptions that concurrency depends on to maintain coherency. You'd need to do thorough analysis of the code to determine where special care is needed, and even then, it won't be trivial setting it up in a way that avoids deadlock because you have to understand what the threads are doing before you can say if it's safe for one thread to wait for another (since they could end up waiting for each other).

Whereas running code meant for a different OS just requires implementing that OS' API (and behaviour, possibly including undocumented behaviour some code relies on, which can vary from application to application, hence windows compatibility modes where they add a translation layer themselves). Not saying this is trivial, but compared to the above problem, it kinda is.

Not that ARM support is impossible, just if they manage that, it will be proclaimed loudly, not something that requires digging. If they don't say it supports ARM, just assume it doesn't.

[–] netweirdo@lemmy.zip 4 points 3 weeks ago

While Wine by itself won't have that support, there is work being done on Wine-on-FEX to run x86 Windows apps on ARM Linux, being funded by Valve as they plan to use it on the Steam Frame, so it's closer than you might think.

[–] bufalo1973@piefed.social 2 points 3 weeks ago (1 children)

So an ARM ReactOS is more likely than an ARM Wine then, I guess.

[–] Buddahriffic@lemmy.world 3 points 3 weeks ago

Yeah, when you're compiling from source code, it's much easier to add in ARM support. Kernels do need to handle more hardware-specific stuff, like interrupt handling, context switching, feature enablement and the like will likely need custom ASM code and might have different parameters/events to handle. But at the user level, you can often compile for ARM by just changing a few command line arguments and it'll be fine as long as you don't rely on inline ASM and have ARM versions of any libraries you need.

You still might need to do some adjustments for specific behavior differences when it comes to concurrency and atomicity of operations. It didn't surprise me to see that the previous attempt to make an ARM ReactOS didn't support multi-threading, because trying to enable it was probably an unreliably buggy mess with race conditions all over the place.

[–] cloudskater@pawb.social 1 points 3 weeks ago

Read this as Wine 1.0 at first lol