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

571–580 of 694 posts

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

#571

Post by wing-_-nuts »

imtringued wrote: post #476
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

Yeah, PC games are like console cartridges. You plug them into a compatible slot and they work.

What? Look, things have gotten much better, but pc gaming, esp via proton is no where near as seamless as playing on console.

In fact, I went with console + linux laptop for ages simply because that combo excelled at their respective roles, were cheaper together than a gaming pc, and it 'just worked'.

I did eventually cave and build another gaming pc, but that was after I acknowledged that I could push out on the price / perf curve to something less 'optimal' (and it let me play with local LLMs)

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

#572

Post by wing-_-nuts »

ChocolateGod wrote: post #565
LanceH wrote: post #559

Earlier quoted context omitted.

You let the people run their own servers and kick cheaters. That's one solution which has actively been taken away over the years.

People just want to click Play and get dropped in a game, not have to mess with servers.

Vehemently disagree with this. One of the reasons I loved BF4 so much were the community servers, with admins that could kick cheaters / griefers, and you enjoyed playing with the same group of folks. It was also one of the (many) reasons I was not remotely tempted to buy BF6. No servers? Not interested.

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

#573

Post by wing-_-nuts »

Perz1val wrote: post #467
Gigachad wrote: post #348

Earlier quoted context omitted.

I can’t see it happening until valve adds some kind of trusted compute environment. I’m imagining online games could have a flag which enforces secure boot, boot chain attestation, and disables multi tasking features. So while you are playing the game it becomes a single task device, but after you quit it’s fully unlocked again to do whatever you want.

You can't block multitasking, the largest multiplayers have huge crowds who play with friends and talk on discord.

Yeah, playing an audio book in the background while I game is my default mode of play now.

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

#574

Post by Cockbrand »

swiftcoder wrote: post #529
dosisking wrote: post #519

Earlier quoted context omitted.

What's a computer?

It's pretty clear from the context that I meant "general purpose PC". We don't have to get all semantic about everything

I guess this was a quote from this iPad ad: http://youtu.be/Ixy2ql7g3-I

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

#575

Post by zamalek »

IshKebab wrote: post #448
zamalek wrote: post #389

Earlier quoted context omitted.

Windows and Linux trade punches in terms of overall experience. What I've seen around is that if Linux has worse FPS, it tends to have more consistent pacing (it generally has better pacing - but not always, I had to abandon Once Human). Gamer's Nexus has a pretty extensive benchmark video: https://youtu.be/ovOx4_8ajZ8?si=Cx5Q1a-lMMm14H4i . They refuse to compare to Windows, and it kinda makes sense: if it's satisfac…

> if it's satisfactory on Linux for your demands then who cares what Windows can do? Pretty much everyone? If bread and water is satisfactory for your demands then who cares about Beef Wellington? If it was better than Windows they sure as hell would be comparing.

> they sure as hell would be comparing.

You're implying that Gamers Nexus is some form of Linux outlet/content creator. They aren't, they only started doing Linux content this year/late last year (and only plan to do it rarely).

You've taking a surprisingly hostile stance on the one (at the time of writing) pro-Linux comment that suggests that it might not be ready for everyone, and to wait if it's not a good fit.

And it isn't beef wellington vs bread and water. It's 80% lean beef vs 82% lean beef, in the majority of cases (and in either direction). And "suitable for your purposes" also means that 160FPS is really fine if your screen is 144Hz - doesn't matter if Windows does 180FPS (unless you're doing something competitive or extremely latency sensitive).

I think Microsoft can do fine without people tilting at windmills for them.

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

#576

Post by bcjdjsndon »

WD-42 wrote: post #545
bcjdjsndon wrote: post #536

Earlier quoted context omitted.

Did you not read what you quoted?

You didn’t. Steam already provides a runtime to target. SteamOS is largely independent from the actual game runtime. You already don’t need to target “12 versions” or whatever nonsense op posted.

>> When SteamOS gains traction, developers will be able to target exactly one distro with fixed configurations and limited customisations. Valve will set the standard for other distros.

Your quoted quote.

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

#577

Post by CyberDildonics »

Dylan16807 wrote: post #432
CyberDildonics wrote: post #402

Earlier quoted context omitted.

You were saying "reasonable overhead" makes no difference because something "isn't called much". This is not only ambiguous but also not true because latency is important. What calls specifically are you talking about between windows and linux? This was started by someone talking about WaitForMultipleObjects.

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 interprocess communication and one wouldn't.

the difference between those two lock styles shouldn't be more than about a microsecond,

What are you basing this on? Do you have an examples or benchmarks of the actual calls and their timings?

fine for a lock that's only used 100 times a second.

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

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

#578

Post by a_vanderbilt »

KennyBlanken wrote: post #313
neverkn0wsb357 wrote: post #295

Given the current momentum, it feels like (to me) the adage of “Windows is for Games” is going by the wayside. If you look at Steam, and OSs like Bazzite it’s clear the consumer-side is finally shoring up. But that aside, from an economic incentive, game providers (for example Amazon Luna), don’t want to be paying the licenses for running Windows machines for Video Game Streaming on Demand. In fact, at my time there…

Online multiplayer games keep trying to allow linux users in and keep having to lock them out because there's an instant influx of cheaters. The Nintendo Switch (which runs Linux) was a favorite of cheaters after jailbreaks came out. When anyone can compile and run their own kernel with god knows what for modifications, that makes it substantially easier for cheaters and substantially harder for anti-cheat. I don't s…

You should not consider Tim Sweeney's comments on the matter as a reliable source. He was veiling his true motivations behind that statement. The Switch does not run Linux either, it's a custom OS descending from the Wii's iOS.

The cheating issue isn't really a matter of being able to run custom kernel code. You can do the same thing on Windows, which is why remote attestation is a thing for some games. As someone who has developed games for Linux (and Windows / Mac), it's an endless cat and mouse game. So long as the system can execute code that is not yours, you never really are getting perfect anticheat. Ease of loading custom kernel code isn't really a hurdle to that.

I find that client and server based in combination is the robust approach. I once implemented anti-cheat in which the server lied about game state, which a regular client without cheats would act predictably on. Deviation from that behavior is a useful heuristic to build a suspicion score.

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

#579

Post by Sohcahtoa82 »

hedora wrote: post #381
Sohcahtoa82 wrote: post #279

Earlier quoted context omitted.

Unfortunately, the alternative to uncomfortably intrusive anti-cheat is more cheaters, because cheaters don't care about how intrusive their cheats have to be in order to evade anti-cheat. They will happily run hypervisor-level cheats. There's certainly room for improvement on the netcode sometimes (Client-side hit registration is an absolute bone-headed design), but those won't prevent aim bots. Server-side anti-che…

I get that people want to play games with randos and 13-30 yr old basement dwellers on the internet, but the idea never appealed to me. If the vendors said: Disable anticheat and we’ll block you from tournaments / matchmaking, I’d consider that a feature, not a bug. If some IRL friend of mine wants to be an asshole and use auto aimers / see through walls to screw with me, then I have ways to deal with it outside the…

> I get that people want to play games with randos and 13-30 yr old basement dwellers on the internet, but the idea never appealed to me.

When it comes to most competitive games, you're an outlier.

I'm a gamer, and one thing I've learned in my 10+ years reading HN is that there are very few gamers here, and the gamers that are here are a different breed. Significantly less focus on competitive games, more interest in Factorio, and a strong anti-anti-cheat vibe, not to mention pro-Linux. It has certainly created an echo chamber when it comes to gaming-related topics such as anti-cheat.

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

#580

Post by mfinelli »

karlding wrote: post #478
mfinelli wrote: post #242

Earlier quoted context omitted.

Ooh overlayfs is quite interesting. I'll have to take a closer look at that. I imagine it's similar to what MO2 was doing on windows with the virtual filesytem to keep the game directory clean. The stow approach is something that I considered but ultimately rejected for a couple of reasons around handling conflicts of game-installed files as well as how to ultimately handle the symlink lifecycle (eg wrapper to make t…

Keep in mind that overlay file systems are designed to treat the lower layer as read only. Changes made in the merged view are written to the upper layer while the original lower files are untouched. So if you need to persist changes into the lower layers, I think you may need to do tricks like taking snapshots and then swapping the bind mount (maybe with some diffing logic) or some other offline methods.

Ah that's good to know. That makes it more complicated than I was thinking because some mods obivously write data (other than cache etc which could be dropped between runs) that they expect to have persisted. Thanks for the heads up; I'll research this some more but I think it might stop there...
Post reply on HN