Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux gaming is faster because Windows APIs are becoming Linux kernel features

xda-developers.com

Post reply on HN
Print view View original

601–610 of 694 posts

Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features

#601

Post by skydhash »

kbolino wrote: post #588
skydhash wrote: post #531

Earlier quoted context omitted.

> 1. An equivalent of kernel level anti-cheats. Ultimately, you can’t trust the user computer unless you go for the secure boot things backed by a hardware key. I’m sure there are multiple ways to bypass anti-cheats on Windows. > 2. Immutability[…] It's distributing games to 12 different distros with a hundreds different configurations and a thousand customisations Does it really matter? You can always ship a statica…

I've been intrigued by the possibility of statically compiled games for Linux but I don't think they're the more compatible option. For typical games and players, the game needs to cooperate and interact with the window system. Even setting aside the X11 vs. Wayland issue, AFAIK neither have promised to maintain compatibility for static binaries.

Aren’t both wayland and X11 protocols? Sure there are toolkits, but they’re not hard requirements (based on the little I know).

Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features

#602

Post by Dylan16807 »

CyberDildonics wrote: post #577
Dylan16807 wrote: post #432

Earlier quoted context omitted.

I wasn't excusing all overhead, I was excusing the difference in overhead caused by making the lock more flexible. Because that's what the discussion is about, a lock that can be shared between processes versus a lock that can't be . The penalty for being "too flexible". But assuming reasonable implementations, the difference between those two lock styles shouldn't be more than about a microsecond, should it? So that…

I was excusing the difference in overhead caused by making the lock more flexible What are the two functions you're comparing and what is the actual difference in overhead that you're talking about? a lock that can be shared between processes versus a lock that can't be. This is a dramatic black and white difference, these would be used for two different things. In that case it's apple and oranges, one would be for i…

> What are the two functions you're comparing

Go ask this comment, because I'm continuing their comparison: https://news.ycombinator.com/item?id=48125795

> In that case it's apple and oranges, one would be for interprocess communication and one wouldn't.

The whole point of the complaint was wtallis claiming the inter-process-capable lock was being used for locks that don't need it! That's the foundation of this conversation!

> What are you basing this on?

Basic coding knowledge and an assumption of competency. There's no good reason for it to slow down more than that when it's used the same way. If you have a reason go ahead and tell me.

> Again, latency isn't about how many times something is called per second. That would matter for throughput.

I addressed both.

The extra latency for using an overly capable lock should be negligible. That's not the problem anyone is worried about.

Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features

#604

Post by GlumWoodpecker »

eigenspace wrote: post #560
KolibriFly wrote: post #436

Earlier quoted context omitted.

This is exactly why Proton feels like the pragmatic path. Native ports are nice in theory, but PC games are rarely just one clean executable anymore

I'd argue that "native" is much more of a state of mind than a clear delineation anyways. Among many game developer studios, the Steamdeck is increasingly becoming the defacto low-spec hardware target. Running their game on a Steamdeck becomes a core part of the QA process, because there's a few million Steamdecks out there actively playing games, and if your game runs on a Steamdeck you basically know it'll also run…

Disagree. The word "native" in a software execution context has a very specific meaning—it means that the software is running on the target hardware with no emulation, translation layer or modification by any middleware. Games running through Proton/WINE will never be native, by definition.

Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features

#605

Post by naniwaduni »

GlumWoodpecker wrote: post #604
eigenspace wrote: post #560

Earlier quoted context omitted.

I'd argue that "native" is much more of a state of mind than a clear delineation anyways. Among many game developer studios, the Steamdeck is increasingly becoming the defacto low-spec hardware target. Running their game on a Steamdeck becomes a core part of the QA process, because there's a few million Steamdecks out there actively playing games, and if your game runs on a Steamdeck you basically know it'll also run…

Disagree. The word "native" in a software execution context has a very specific meaning—it means that the software is running on the target hardware with no emulation, translation layer or modification by any middleware. Games running through Proton/WINE will never be native, by definition.

x86 bytecode isn't the native instruction set on any real hardware you're running games on either, just one of the lowest-level publicly exposed interfaces.

Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features

#606

Post by eigenspace »

GlumWoodpecker wrote: post #604
eigenspace wrote: post #560

Earlier quoted context omitted.

I'd argue that "native" is much more of a state of mind than a clear delineation anyways. Among many game developer studios, the Steamdeck is increasingly becoming the defacto low-spec hardware target. Running their game on a Steamdeck becomes a core part of the QA process, because there's a few million Steamdecks out there actively playing games, and if your game runs on a Steamdeck you basically know it'll also run…

Disagree. The word "native" in a software execution context has a very specific meaning—it means that the software is running on the target hardware with no emulation, translation layer or modification by any middleware. Games running through Proton/WINE will never be native, by definition.

From that point of view, native software effectively does not exist, and was long gone before the Linux project even started.

Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features

#608

Post by bigyabai »

quibono wrote: post #598
bigyabai wrote: post #596

Earlier quoted context omitted.

DCS World and MSFS2020 play on Linux just fine. MSFS2020 is flawless; DCS World has a few visual glitches with smoke tessellation and MFD textures that need to be converted before working, but besides that it's great. I fly modded and first-party modules on multiple maps, hours at a time, zero complaints.

That’s interesting… have you tried MSFS2024? That’s my main driver for now; god it would be amazing if I could run it on Linux. I’ll definitely need to try DCS on Arch! By the way - what module would you recommend (apart from F-18)?

Haven't tried MSFS2024, but ProtonDB suggests that it works okay. The 2020 version is definitely set-and-forget once you log into your Microsoft account.

Module-wise - once you have the F/A-18, a lot of the other modules feel like wasted money. I can wholeheartedly recommend the AJS37 Viggen when it's on sale, for $30 it's got a lot of flexibility and surprisingly simple systems for a 1970s jet. It's very easy to memorize the cold start process in the Viggen too, which makes it a joy to get off the tarmac. The JF-17 is also a barrel of fun, and much easier to fly/fight in than the F-16 if you don't have a HOTAS and don't need JHMCS. Besides that, the only other modules I can fully recommend is the Syria map, Persian Gulf map, and Flaming Cliffs for all the modded planes it unlocks. Not personally a fan of the Sinai map right now, and the Apache is very difficult to fly without a copilot/gunner in the second seat. Black Shark 3 is fun, but one of the most goddamn complex modules in the game. Even with translated cockpit labels, you'll be permanently conjoined to a YouTube guide telling you how to do the most basic flight maneuvers.

Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features

#609

Post by not_a9 »

progforlyfe wrote: post #166
ToucanLoucan wrote: post #128

Earlier quoted context omitted.

I'm looking to finally get off Windows for good. My experience with the SteamDeck started me, later I upgraded to a ROG Ally X for beefier performance but found Windows insufferable on a handheld, and installed SteamOS. I was blown away by the performance gains. A few months later I installed Kubuntu for the first time since 2013 or so, Steam shortly after, and while the desktop linux route is definitely more taxing…

Modding will continue to be a challenge, but doable, thing, until more mod devs get onboarded to Linux themselves. If the mod devs enjoy using Linux, they'll probably start building mods with UIs native to Linux. I would say custom modding and online multiplayer anti-cheat systems are the last real hold outs, and even then it doesn't affect every game.

Does Wine have any debugging tools with equivalent developer experience to Visual Studio’s debugger?

Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features

#610

Post by not_a9 »

ChocolateGod wrote: post #563
skydhash wrote: post #531

Earlier quoted context omitted.

> 1. An equivalent of kernel level anti-cheats. Ultimately, you can’t trust the user computer unless you go for the secure boot things backed by a hardware key. I’m sure there are multiple ways to bypass anti-cheats on Windows. > 2. Immutability[…] It's distributing games to 12 different distros with a hundreds different configurations and a thousand customisations Does it really matter? You can always ship a statica…

> I’m sure there are multiple ways to bypass anti-cheats on Windows. Of course, you can use DMA over Thunderbolt, but the bar is so high (cost, specialised hardware) that most people who cheat won't do it. > Does it really matter? You can always ship a statically compiled games This isn't completely viable, you can't statically link the graphics driver.

Aren’t most DMA cards just PCI-E FPGA things? In any case, DMA doesn’t magically make your shit UD - you can look at Unknowncheats and see.
Post reply on HN