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

621–630 of 694 posts

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

#621

Post by somat »

tombert wrote: post #395
babypuncher wrote: post #192

Earlier quoted context omitted.

Don't most monitors ship with DisplayPort cables? All of mine have. HDMI is more popular with TVs/home theater systems.

Outside of the ones built into laptops, all my "monitors" for the last decade have been TVs, just because they tend to be cheaper at a "price to size" level. None of them ever seem to have DisplayPort.

There is supposed to be some sort of conspiracy where the HDMI consortium actively tries to keep display port off of TV's.

Not sure if I buy it, how would that even work? lower licensing fees when no display port? I suspect the real answer is that HDMI managed to capture the market for digital video links and while display port is better it is not enough better for people to want to make the incompatibility jump.

But.... Conversely it does almost make sense. because finding DP on a TV is super rare, nobody is even trying. Historically you would find all sorts of rareish connectors on TV's(component video, s-video) so.. conspiracy... perhaps.

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

#622

Post by Dylan16807 »

CyberDildonics wrote: post #617
Dylan16807 wrote: post #602

Earlier quoted context omitted.

> 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 conve…

Basic coding knowledge and an assumption of competency. This is just saying "I just know", but what specific function and basic timings are you going off of? If you don't know, why are you so sure of the numbers? 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! They were saying it's rare to nee…

If you're not actually using it between processes, the overhead could be as small as an extra conditional. For an upper bound I think a couple wasted syscalls makes sense. Why would it be significantly slower than that?

But whatever, let's focus on the actual point:

> They were saying it's rare to need IPC lock for video games and I don't think that's true, then I gave a scenario where you would use one.

And I was pointing out that a voice IPC lock is still "rare" when we use the most appropriate definition of "rare" for this context. In this context of worrying that using the wrong kind of lock will slow the game down, how often we're using the lock matters. If we go 50 million CPU cycles between uses, it's "rare".

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

#623

Post by blep_ »

wazulu wrote: post #387

That's a great twist! Very few people traded Bill Gates a linker for a compiler!

The way you worded this has me imagining the counterfactual world where lots of people traded Bill Gates a linker for a compiler.

Compilers cost real money back then. Word got out that this was how you got a free compiler. You just wrote a linker, and you got in touch with Bill and offered it to him. (You did have to write your linker in a single huge file of assembly, because you didn't have a compiler or a linker yet. It was fine, more programmers knew assembly back then.)

Microsoft has thousands of linkers. They're the linker company now.

Most of their other products started as test cases for their linkers, that they also happen to sell separately as a side business because why not.

Excel is a notable exception, because due to a series of overengineering decisions, it actually is a linker that gradually gained spreadsheet features.

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

#624

Post by dullcrisp »

throw98226 wrote: post #332
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.

If you wanted to get into development mode in CTOS, the keyword was 'developement' - an e between the p and the m. Worked on this system back in early 1990 as a developer.

developéer

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

#625

Post by jurgenburgen »

ms_menardi wrote: post #616
naniwaduni wrote: post #605

Earlier quoted context omitted.

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.

if it's the lowest level available, then it's as close to "native" as we can get, so therefore it has to qualify, if we want to consider anything at all to be running "natively"

Isn’t that moving the goalposts? If an API isn’t exposed for native code then maybe we should just accept that we can’t write native code anymore instead of stretching the definition.

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

#626

Post by tempaccountabcd »

trashface wrote: post #109

Feels like there is some real momentum on linux gaming now. I mostly play older games but I've gotten most of them working acceptably in proton on my old system 76 laptop (oryp5, with a nvidia 2060; ~7 years old). The laptop actually has plenty of power for the games I play, but I underclock to keep the heat/fan speeds down (been doing the same on the win10 install on the same system), still getting acceptable framer…

[dead]

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

#627

Post by ThatPlayer »

LanceH wrote: post #559
simonask wrote: post #546

Earlier quoted context omitted.

"Linux" doesn't need to do anything here. What's missing is for anticheat vendors to develop kernel modules for Linux in addition to their Windows drivers. I personally hope they never do, because present day anticheat systems are literally closed-source rootkits. You should not let that software onto any computer you own. But then I don't really have a horse in the race, because I don't find competitive gaming with…

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

If you look at modern games that still do this, plenty of them add additional anticheats, not less.

FiveM, modded servers for GTAV, had anticheats before Rockstar added any which already prevented Linux players. Face IT for CS2 does the same.

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

#628

Post by ThatPlayer »

Gigachad wrote: post #615
flaunf221 wrote: post #523

Earlier quoted context omitted.

> I have a 2019 RX5700 XT So you have very old hardware, can barely play modern AAA games (if ever), and are still happy. Good for you. But your opinion is relevant to average gamer who enjoys playing games released in current year in the same way that someone drinking instant coffee can advise on coffee beens that it's all just caffeine in the end.

Which games will not run on a 5700xt? I’ve played a load of latest release games on a steam deck which is like 15% of the power of that GPU.

Not a power issue but a feature issue. No ray tracing stops Indiana Jones and Doom Dark Ages (though you can do it in software on Linux): https://youtu.be/aU2qwlCLWm8 . Doom Dark Ages also added a check for Vulkan Variable Rate Shading, requiring a workaround to spoof it. Mesh shader requirement prevents Final Fantasy 7 Rebirth from running.

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

#629

Post by ben-schaaf »

sayamqazi wrote: post #437
ben-schaaf wrote: post #349

Earlier quoted context omitted.

All these games already have an authoritative server. These cheaters aren't breaking the rules of the game by being invincible, super speedy, etc. they're aim-botting and wall hacking. Those cheats can't be prevented with authoritative networking.

I dont know what kind of authoritative server Apex Legend uses that let the infamous "Tufi" hacker do what he did for so long. IMO it should be trivial to ban someone hitting more than 80% of their shots as headshots,, dual weilding weapons that were never supposed to be dual-weilded. Charge rifle beam permanently shooting and swapping armors from miles away

There's a big difference between authoritative networking with some security holes and non-authoritative networking. Note also that hitting 100% headshots is entirely within the rules of the game; it has nothing to do with the networking implementation.

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

#630

Post by CyberDildonics »

Dylan16807 wrote: post #622
CyberDildonics wrote: post #617

Earlier quoted context omitted.

Basic coding knowledge and an assumption of competency. This is just saying "I just know", but what specific function and basic timings are you going off of? If you don't know, why are you so sure of the numbers? 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! They were saying it's rare to nee…

If you're not actually using it between processes, the overhead could be as small as an extra conditional. For an upper bound I think a couple wasted syscalls makes sense. Why would it be significantly slower than that? But whatever, let's focus on the actual point: > They were saying it's rare to need IPC lock for video games and I don't think that's true, then I gave a scenario where you would use one. And I was po…

how often we're using the lock matters.

No, latency is what matters.

And I was pointing out that a voice IPC lock is still "rare" when we use the most appropriate definition of "rare"

This isn't really a point with explanation, it's just you saying 'nu uh', even though that was just a single example.

Post reply on HN