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

321–330 of 694 posts

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

#321

Post by KennyBlanken »

Sohcahtoa82 wrote: post #279
zuzululu wrote: post #254

I support linux gaming btw but I can't help but feel every narrative glosses over that certain games are going to require uncomfortably intrusive anti-cheating systems. I'm just realizing that I can't play Battlefield 6 and I do wonder what the path is. I don't think it's ever going to be supported on Linux or Mac.

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…

Hypervisor anti-cheat is old hat. The current 'state of the art' is either a DMA card that pretends to be a sound or network card but really is constantly reading and writing directly to RAM in the game's memory space.

The other 'state of the art' which is much cheaper, easier, and essentially impossible to detect on a hardware/equipment level, are the AI-based systems that examine the video and generate inputs via USB, emulating controllers or keyboards and mice. It's a huge problem on console right now and can only be detected via server-side analysis.

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

#322

Post by YPPH »

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…

>The Nintendo Switch (which runs Linux) was a favorite of cheaters after jailbreaks came out.

If you're saying the Nintendo Switch system software is Linux-based, I don't think that's correct. It's a proprietary system based on a microkernel architecture.

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

#323

Post by JoeAltmaier »

hnthrowaway0315 wrote: post #195
JoeAltmaier wrote: post #8

Used to be a staff member working on an x86 OS called CTOS. I realized if I implemented a couple of traps, we could run command-line DOS programs. So I did. And it worked. Dev tools, text processing, piped commands all worked. It helped that the DOS executable format was the same as the CTOS format - because we had traded Bill Gates our linker (which produces executables) for his BASIC compiler.

Looks like this one? https://en.wikipedia.org/wiki/Convergent_Technologies_Operat... Thanks for sharing, never heard about it before. What was kernel programming back then? Briefly checked the wikipedia and looks like CTOS was kinda big in the government space back in the 80s.

It was popular with govt because it came with an HDLC network build-in, server/client depended on the OS you booted. This saved you a network administrator.

The kernel was in Intel ASM86 but the rest of the OS was written in PLM86. When I joined it was 2MB of code on a 128K 8086 cpu. By the time I left it was 9MB of code running on an 80386.

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

#324

Post by KennyBlanken »

skupig wrote: post #318
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 don't think that's necessarily true, I think companies are lazy and highly invasive anticheat is an easy win they can license from a 3rd party. Algorithmic security, server-side heuristics, and human review can get you far. I have very, very rarely seen a blatant cheater in Overwatch (maybe 3 times in 10 years?), for example, and yet it's been playable via WINE for almost its entire lifetime.

Overwatch is more dependent upon teamwork, ability usage, positioning, etc.

Cheating is endemic in BR and tactical shooter type games. I remember one f2p game was deleting 50,000 cheater accounts every month.

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

#325

Post by DevKoala »

Mariajaved906 wrote: post #212
9x39 wrote: post #211

Finding a way to get the multiplayer studios to get Linux support for their competitive games like Valve does could crack a wedge in the market for mainstream users to get in, particularly in those who don't want to pay the Windows tax (not everyone is willing to experiment or go unlicensed). I can't prove it, but the Steam Deck has probably torn down a lot of barriers for mainstream use among the crowd that care abo…

Yeah, anti-cheat support is probably the biggest barrier right now. The Steam Deck already showed that many gamers do not really care about the OS as long as their favorite games work smoothly.

Quite the contrary. I care about the OS and that’s why I switched to Linux gaming. The experience wrapping the game is just so much better.

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

#326

Post by theshackleford »

SchemaLoad wrote: post #283
anonymousab wrote: post #169

Earlier quoted context omitted.

5% would already be well within the margin of difference for separate identical clean installations of windows on the same hardware. But the issue is that it is many multiples of that, especially on the most common PC gaming hardware (Nvidia GPUs), often more than a 25% difference in framerates. Not so important at 144fps, but very important at a 60fps baseline and for genres like fighting games. A lot of people don'…

I'd guess that the difference only matters if you have the latest most expensive gear pushed to the limit. I have a 2019 RX5700 XT and one of the DDR4 ryzen 5 cpus and all of my games run flawlessly on Linux with great performance. I've long since decided that buying the latest top end hardware is just spending a lot of money to be upset by buggy drivers or not being able to get 5000 fps in a benchmark but has no rea…

> all of my games run flawlessly on Linux with great performance.

Your definition of great performance is not mine, but it’s fantastic to watch Linux users continue to hand wave away real issues whilst continually claiming the same or better performance across the board, which is provably false.

> but has no real gains in how fun games are.

It absolutely does for me. Modern displays are absolutely dogshit. I won’t play at anything less than 144hz, as much as I can I aim for 200hz and I want that with consistent frame times.

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

#327

Post by marcus_holmes »

SchemaLoad wrote: post #283
anonymousab wrote: post #169

Earlier quoted context omitted.

5% would already be well within the margin of difference for separate identical clean installations of windows on the same hardware. But the issue is that it is many multiples of that, especially on the most common PC gaming hardware (Nvidia GPUs), often more than a 25% difference in framerates. Not so important at 144fps, but very important at a 60fps baseline and for genres like fighting games. A lot of people don'…

I'd guess that the difference only matters if you have the latest most expensive gear pushed to the limit. I have a 2019 RX5700 XT and one of the DDR4 ryzen 5 cpus and all of my games run flawlessly on Linux with great performance. I've long since decided that buying the latest top end hardware is just spending a lot of money to be upset by buggy drivers or not being able to get 5000 fps in a benchmark but has no rea…

This. I understand that getting your desktop fps to ridiculous heights is a hobby in and of itself, an obsession that I don't share at all, and good luck to them that do. But I'm colourblind and have the reaction speed of a slug. Anything over 25fps is wasted on me.

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

#328

Post by coconut08 »

chromadon wrote: post #199

I use Bazzite for all my gaming (Returnal at the minute) and it works unbelievably well. I don’t tinker with any of the proton version. I just press play. I recently completed Stellar Blade with zero issues. I don’t even shutdown the machine, I just hit the power to sleep it. Instantly resumes where I left off. Incredible to see just how far it’s come.

im using bazzite with an amd cpu and amd gpu and sleep doesn't work properly? what motherboard/cpu/gpu do you have? did you have to do something special to make it work?

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

#329

Post by harry8 »

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…

The status quo's days are numbered. Online chess shows how.

An AI will play these games like a human but better. The AI can be totally separate from the windows box wearing anti-cheat ankle bracelets just as your brain a separate thing to the windows box when when you play. It can interact with the box via keyboard, mouse or controller.

No windows kernel module is useful in detecting and deterring chess cheating no matter how fanciful or factual the vibrating "device" stories are.

Anti-cheat by kernel module, it's day will be entirely done very soon if it isn't already.

"Any time you beat a computer at a game it let you win." Are we there yet? If not, how long?

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

#330

Post by JoeAltmaier »

bonzini wrote: post #206
dullcrisp wrote: post #170

Earlier quoted context omitted.

Why/when are traps used rather than explicit system calls? Is it just historical coevolution? Or is the idea that the user mode program doesn’t need to know that it’s unprivileged? Or is it just repurposing the error handler path to perform privileged operations?

At the time of DOS, x86 didn't have multiple privileges. The system call instruction was typically INT, the software interrupt instruction. Later on the 386 Intel added virtual 8086 mode which trapped to the kernel privileged instruction exception also for certain instructions that had to be virtualized, among them INT.

Yes, exactly.

We used a set of INT instructions in well-known low memory addresses that all jumped to the same place. We had an ASM file that you linked with, that had sixteen different address combinations for each.

The common entry point would look back on the stack and calculate from the return address which entry point had been called, and run the appropriate kernel call. We called it the CS:IP hack.

In the context of this post, the DOS INT10 and INTx(I forget) required the caller to load registers with the desired system call number, then perform the trap instruction in their code. Fortunately CTOS didn't need those particular software interrupts, so I could implement them for my purposes.

Post reply on HN