1. 📰 Wine 11 rewrites how Linux runs Windows games at the kernel level, and the speed gains are massive (direct link) (👍881 👎3)
from Linux Gaming (!linux_gaming@lemmy.world)
Posted by monica_b1998
2. 🖼️ When you're the type of person who commits. (xpost, because the Factorio joke inspired me) (direct link) (👍802 👎9)
from Games (!games@lemmy.world)

original thread had gaming relevance :
https://lemmy.world/post/38269946
If this is hated on I'll delete the thread (EDIT) I guess not.
Posted by Skullgrid
3. 🖼️ Achievements (direct link) (👍582 👎13)
from Gaming (!gaming@lemmy.world)

Posted by The_Picard_Maneuver
4. 📰 Stop Killing Games throw weight behind California bill that would force companies to either keep games working independently after server shutdowns or issue refunds (direct link) (👍354 👎1)
from Gaming (!gaming@lemmy.zip)

Stop Killing Games throw weight behind California bill that would force companies to either keep games working independently after server shutdowns or issue refunds
The Californian legislation cited in Stop Killing Games' latest progress update on Reddit is dubbed the "Protect our Games Act", and was initially put forward by Chris Ward - a member of California's State Assembly - in February this year. Stop Killing Games say they had a hand in "advising on the drafting of" it. Funnily enough, the latter's also the date of a European Parliament public hearing about Stop Killing Games' citizens’ initiative - the petition the group recently submitted to the body. Finally, Stop Killing Games organiser Moritz Katzner noted that he was called in to advise the UK government's Department for Culture, Media & Sport on unspecified matters related to the campaign last week. He added that Stop Killing Games are "planning to build a stronger presence in the UK", but didn't provide any more details. 🖊️️🤖
Posted by GamingBot
5. 🖼️ Nostalgia hits hard (direct link) (👍283 👎1)
from RetroGaming (!retrogaming@lemmy.world)

Playing Need for Speed: Most Wanted on my PS2 and Sony Trinitron, even the calendar is form 2009
The room at my parents house seems permanently stuck in mid 2000s, too bad I can't take the TV with me
Posted by los0220
6. 🖼️ Should have gotten that 3% interest mortgage back in the day. (direct link) (👍173 👎2)
from Gaming (!gaming@lemmy.ml)

Posted by UltraGiGaGigantic
7. 📰 House Flipper is free on Steam (direct link) (👍163 👎0)
from Games (!games@sh.itjust.works)

House Flipper on Steam
Take job offers from nearby residents - clean up, paint walls, install heaters, showers, and air conditioners, or even furnish their whole property! Once the grateful clients pay you for your solid work, it's time to get your own house. Get rid of broken glass shards, litter, and leftover pieces of furniture, to prepare the place for a complete makeover! Regardless if you plan to create the house of your dreams, help the residents with their renovations or feel the need to smack some walls -House Flipper is here for You! So just sit comfortably, let go off your usual daily routine, and delve into the world of House Flipper... into your world! 🖊️️🤖
Posted by BobbleBubble
8. 📰 lutris-minus-ai (direct link) (👍60 👎13)
from Linux Gaming (!linux_gaming@lemmy.ml)
ridge/lutris-minus-ai: Lutris desktop client. Forked from the last commit before AI was (to my understanding) used in the project.
LutrisAbout this forkThis is a fork of Lutris before AI was included in commit logs. Running LutrisIf you have not installed Lutris through your package manager and are using the source package, it is recommended that you install lutris at least once, even an older version to have all dependencies available. Via the website, it is also possible to sync your Steam library to your Lutris library. The Lutris client only stores a token when connected with the website, and your login credentials are never saved. Configuration files~/.local/share/lutris : The client, runners, and game configuration files There is no need to manually edit these files as everything should be done from the client. 🖊️️🤖
Posted by Twig
9. 💬 Weekly Recommendations Thread: What are you playing this week? (direct link) (👍40 👎1)
from Patient Gamers (!patientgamers@sh.itjust.works)
Posted by BurntWits
10. 💬 Emulator games as a way to postpone your purchases (direct link) (👍27 👎1)
from Patient Gamers (!patientgamers@lemmy.ml)
Go to https://retroachievements.org/ for emulator. Check out games total players or https://www.vgchartz.com/gamedb/ for inspiration and dont hesitate to play long time classics for selected consoles, handhelds.
Posted by xelar
11. 📰 Towns releases source code (direct link) (👍26 👎0)
from OpenSourceGames (!opensourcegames@lemmy.ml)

Source Code Release
Posted by basxto
12. 📰 [Early Access] 2DOM! is a Chill 2D sidescroller physics-based chain reaction puzzle game featuring dominoes! (direct link) (👍2 👎1)
from Indie Gaming (!indiegaming@lemmy.world)

[Early Access] 2DOM! by Oka's Games
As a solo indie developer who dreams of working on games full time, I am unable in today's job climate. If the game is profitable early on, that may result in me converting to part-time or full-time, meaning faster updates and more content! Players have access to a puzzle level editor which you can use to build, test, save and load your levels. 3 free post-release content updates are planned which will add more spawnables, more campaign branches. Early Access price is $4.99, with the launch price being set at $6.99. 🖊️️🤖
Posted by Oka
Inactive communities 👻
These communities have had no posts in the last month:
- Let's Talk About Games
- Where Am I?
- Gyro Gaming
- Welcome to Gyro Gaming subreddit, where people can share their passion for Gyroscopic Controls in Video Games, such as Camera Aiming, Vehicle Steering, Typing, etc.
Here is a popular post from one of the inactive communities. 🪦♻️
💬 What are you hoping to buy during Steam summer sale? (direct link), posted in Let's Talk About Games (👍51 👎3)
For me, I am hoping to see discounts on:
- Steam Deck OLED
- Expedition 33 (probably worth the full price but I am not sure if the timing based combat is for me)
- Fantasy Life i
- Indiana Jones and the Great Circle
Posted by cloudless
The main links are using lemmyverse.link which should redirect to the post on your own instance. If you have not used this before, you may need to go direct to https://lemmyverse.link/ and click on 'configure instance'. Some apps will open posts correctly when using the direct link.
️🤖 indicates a summary generated using AI - 🖋️ TLDR This, 🖊️ news3k, 🖍 Deepseek. It is possible that the summary does not accurately convey the meaning of the original article, refer to the source material if in any doubt.
Archive link: https://archive.ph/Ze3or
Linux gaming has come a long way. When Valve launched Proton back in 2018, it felt like a turning point, turning the Linux gaming experience from "technically possible if you're okay with a lot of pain" to something that more or less worked. Since then, we've seen incremental Wine releases, each one chipping away at compatibility issues and improving performance bit by bit. Wine 10, Wine 9, and so on; each one a collection of bug fixes and small improvements that kept the ecosystem moving forward.
Wine 11 is different. This isn't just another yearly release with a few hundred bug fixes and some compatibility tweaks. It represents a huge number of changes and bug fixes. However, it also ships with NTSYNC support, which is a feature that has been years in the making and rewrites how Wine handles one of the most performance-sensitive operations in modern gaming. On top of that, the WoW64 architecture overhaul is finally complete, the Wayland driver has grown up a lot, and there's a big list of smaller improvements that collectively make this feel like an all-new project.
I should be clear: not every game is going to see a night-and-day difference. Some titles will run identically to before. But for the games that do benefit from these changes, the improvements range from noticeable to absurd. And because Proton, SteamOS, and every downstream project builds on top of Wine, those gains trickle down to everyone.
Everything up until now was a workaround
Esync and fsync worked, but they weren't ideal
If you've spent any time tweaking Wine or Proton settings, you've probably encountered the terms "esync" and "fsync" before. Maybe you toggled them on in Lutris, or noticed them in Proton launch options, without fully understanding what they do. To understand why NTSYNC matters, you need to understand the problem these solutions were all trying to solve.
Windows games, especially modern ones, are heavily multi-threaded. Your CPU isn't just running one thing at a time, and instead, it's juggling rendering, physics calculations, asset streaming, audio processing, AI routines, and more, all in parallel across multiple threads. These threads need to coordinate with each other constantly. One thread might need to wait for another to finish loading a texture before it can render a frame. Another might need exclusive access to a shared resource so two threads don't try to modify it simultaneously.
Windows handles this coordination through what are called NT synchronization primitives... mutexes, semaphores, events, and the like. They're baked deep into the Windows kernel, and games rely on them heavily. The problem is that Linux doesn't have native equivalents that behave exactly the same way. Wine has historically had to emulate these synchronization mechanisms, and the way it did so was, to put it simply, not ideal.
The original approach involved making a round-trip RPC call to a dedicated "kernel" process called wineserver every single time a game needed to synchronize between threads. For a game making thousands of these calls per second, that overhead added up fast and served to be a bottleneck. And it was a bottleneck that manifested as subtle frame stutters, inconsistent frame pacing, and games that just felt a little bit off even when the raw FPS numbers looked fine.
Esync was the first attempt at a workaround. Developed by Elizabeth Figura at CodeWeavers, it used Linux's eventfd system call to handle synchronization without bouncing through the wineserver. It worked, and it helped, but it had quirks. Some distros ran into issues with file descriptor limits, since every synchronization object needed its own file descriptor, and games that opened a lot of them could hit the system's ceiling quite quickly.
Fsync came next, using Linux futexes for even better performance. It was faster than esync in most cases, but it required out-of-tree kernel patches that never made it into the mainline Linux kernel or to upstream Wine out of the box. That meant you needed a custom or patched kernel to use it, which is fine for enthusiasts running CachyOS or Proton-GE, but not exactly accessible for the average user on Ubuntu or Fedora. Futex2, often referred to interchangeably with fsync, did make it to Linux kernel 5.16 as futex_waitv, but the original implementation of fsync isn't that. Fsync used futex_wait_multiple, and Futex2 used futex_waitv. Applications such as Lutris still refer to it as Fsync, though. It's still kind of fsync, but it's not the original fsync.
Here's the thing about both esync and fsync: they were workarounds. Clever ones, but workarounds nonetheless. They approximated NT synchronization behavior using Linux primitives that weren't designed for the job, and certain edge cases simply couldn't be handled correctly. Operations like NtPulseEvent() and the "wait-for-all" mode in NtWaitForMultipleObjects() require direct control over the underlying wait queues in ways that user-space implementations just can't reliably provide.
NTSYNC reworks everything
Synchronization at the kernel-level, rather than in user-space
NTSYNC takes a completely different approach. Instead of trying to shoehorn Windows synchronization behavior into existing Linux primitives, it adds a new kernel driver that directly models the Windows NT synchronization object API. It exposes a /dev/ntsync device that Wine can talk to, and the kernel itself handles the coordination. No more round trips to wineserver, no more approximations, and the synchronization happens in the kernel, which is where it should be. And it has proper queue management, proper event semantics, and proper atomic operations.
What makes this even better is that NTSYNC was developed by the same person who created esync and fsync in the first place. Elizabeth Figura has been working on this problem for years, iterating through multiple kernel patch revisions, presenting the work at the Linux Plumbers Conference in 2023, and pushing through multiple versions of the patch set before it was finally merged into the mainline Linux kernel with version 6.14.
The numbers are wild. In developer benchmarks, Dirt 3 went from 110.6 FPS to 860.7 FPS, which is an impressive 678% improvement. Resident Evil 2 jumped from 26 FPS to 77 FPS. Call of Juarez went from 99.8 FPS to 224.1 FPS. Tiny Tina's Wonderlands saw gains from 130 FPS to 360 FPS. As well, Call of Duty: Black Ops I is now actually playable on Linux, too. Those benchmarks compare Wine NTSYNC against upstream vanilla Wine, which means there's no fsync or esync either. Gamers who use fsync are not going to see such a leap in performance in most games.
The games that benefit most from NTSYNC are the ones that were struggling before, such as titles with heavy multi-threaded workloads where the synchronization overhead was a genuine bottleneck. For those games, the difference is night and day. And unlike fsync, NTSYNC is in the mainline kernel, meaning you don't need any custom patches or out-of-tree modules for it work. Any distro shipping kernel 6.14 or later, which at this point includes Fedora 42, Ubuntu 25.04, and more recent releases, will support it. Valve has already added the NTSYNC kernel driver to SteamOS 3.7.20 beta, loading the module by default, and an unofficial Proton fork, Proton GE, already has it enabled. When Valve's official Proton rebases on Wine 11, every Steam Deck owner gets this for free.
All of this is what makes NTSYNC such a big deal, as it's not simply a run-of-the-mill performance patch. Instead, it's something much bigger: this is the first time Wine's synchronization has been correct at the kernel level, implemented in the mainline Linux kernel, and available to everyone without jumping through hoops.
WoW64 is finally complete
Even 16-bit applications work
If NTSYNC is the headline feature, the completion of Wine's WoW64 architecture is the change that will quietly improve everyone's life going forward. On Windows, WoW64 (Windows 32-bit on Windows 64-bit) is the subsystem that lets 32-bit applications run on 64-bit systems. Wine has been working toward its own implementation of this for years, and Wine 11 marks the point where it's officially done.
What this means in practice is that you no longer need 32-bit system libraries installed on your 64-bit Linux system to run 32-bit Windows applications. Wine handles the translation internally, using a single unified binary that automatically detects whether it's dealing with a 32-bit or 64-bit executable. The old days of installing multilib packages, configuring ia32-libs, or fighting with 32-bit dependencies on your 64-bit distro thankfully over.
This might sound like a small quality-of-life improvement, but it's a massive piece of engineering work. The WoW64 mode now handles OpenGL memory mappings, SCSI pass-through, and even 16-bit application support. Yes, 16-bit! If you've got ancient Windows software from the '90s that you need to run for whatever reason, Wine 11 has you covered.
For gaming specifically, this matters because a surprising number of games, especially older ones, are 32-bit executables. Previously, getting these to work often meant wrestling with your distro's multilib setup, which varied in quality and ease depending on whether you were on Ubuntu, Arch, Fedora, or something else entirely. Now, Wine just handles it for you.
The rest of Wine 11 isn't just filler
There are more fixes, too
It's easy to let NTSYNC and WoW64 steal the spotlight, but Wine 11 is packed to the gills with other stuff worth talking about.
The Wayland driver has come a long way. Clipboard support now works bidirectionally between Wine and native Wayland applications, which is one of those things you don't think about until it doesn't work and it drives you mad. Drag-and-drop from Wayland apps into Wine windows is supported. Display mode changes are now emulated through compositor scaling, which means older games that try to switch to lower resolutions like 640x480 actually behave properly instead of leaving you with a broken desktop. If you've been holding off on switching from X11 to Wayland because of Wine compatibility concerns, Wine 11 removes a lot of those barriers.
On the graphics front, EGL is now the default backend for OpenGL rendering on X11, replacing the older GLX path. Vulkan support has been bumped to API version 1.4, and there's initial support for hardware-accelerated H.264 decoding through Direct3D 11 video APIs using Vulkan Video. That last one is particularly interesting for games and applications that use video playback for things like cutscenes or in-game streaming.
Force feedback support has been improved for racing wheels and flight sticks, which is great news if you're running a sim setup on Linux. As well, Bluetooth has received a new driver with BLE services and proper pairing support, MIDI soundfont handling has been improved for legacy game music, and there are a couple of minor extras like Zip64 compression support, Unicode 17.0.0 support, TWAIN 2.0 scanning for 64-bit apps, and IPv6 ping functionality.
Thread priority management has been improved on both Linux and macOS, which helps with multi-threaded application performance beyond just the NTSYNC gains. ARM64 devices can now simulate 4K page sizes on systems with larger native pages, which keeps the door open for Wine on Arm hardware. And with more Arm-based Linux devices showing up every year, that matters more than it used to.
Plus, there are a ton of bug fixes. Games like Nioh 2, StarCraft 2, The Witcher 2, Call of Duty: Black Ops II, Final Fantasy XI, and Battle.net all received specific compatibility fixes, which is additional to the broader improvements made across the board that will improve performance and compatibility across significantly more titles.
Wine 11 is a big release, and it's not just NTSYNC that makes it the case. Sure, NTSYNC alone would have made it worth paying attention to, but combined with the WoW64 completion, the Wayland improvements, and the sheer volume of fixes, it's the most important Wine release since Proton made Linux gaming viable. Everything built on top of Wine, from Proton to Lutris to Bottles, gets better because of it. If you play games on Linux at all, Wine 11 is worth your time trying out.
The numbers are wild. In developer benchmarks, Dirt 3 went from 110.6 FPS to 860.7 FPS, which is an impressive 678% improvement. Resident Evil 2 jumped from 26 FPS to 77 FPS. Call of Juarez went from 99.8 FPS to 224.1 FPS. Tiny Tina's Wonderlands saw gains from 130 FPS to 360 FPS.
Might have to make another effort to switch to Linux. Kind of a side question about Linux, is there a good android emulator? On windows I've been using Google play games which has official support for my game of choice but if an emulator will work I don't know what else I use that's locked to windows.
Wine 11 is different. This isn't just another yearly release with a few hundred bug fixes and some compatibility tweaks. It represents a huge number of changes and bug fixes. However, it also ships with NTSYNC support, which is a feature that has been years in the making and rewrites how Wine handles one of the most performance-sensitive operations in modern gaming. On top of that, the WoW64 architecture overhaul is finally complete, the Wayland driver has grown up a lot, and there's a big list of smaller improvements that collectively make this feel like an all-new project.
Wine is the windows compatibility layer that Proton is based on, which is how the Deck plays windows games. So any significant update to wine will directly benefit windows games on Deck, as soon as Proton is updated.
NTsync is the headlining new addition to Wine11. It replaces Esync and Fsync as a much accurate synchronizer. This should:
-
Make games run smoother, removing microstutters and improving frame pacing
-
Significantly improve performance in some older games that could run into major performance bottlenecks from this. You can see some fps increases here, with many of the affected games getting over twice the fps.
NTsync requires kernel support, but Valve added that in steamOS 3.7.20. Wine11's NTsync hasn't made it into Proton experimental yet, but GE-Proton has added support for it already, so it's not hard to try it out.
Wine11 also improves support for older 32 and 16 bit windows applications.
This is an automated archive made by the Lemmit Bot.
The original was posted on /r/games by /u/tapo on 2026-03-24 20:47:20+00:00.



