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

LatencyFleX: A new approach to game latency reduction

ishitatsuyuki.github.io

Post reply on HN
Print view View original

11–20 of 69 posts

Re: LatencyFleX: A new approach to game latency reduction

#11

Post by lbotos »

bullen wrote: post #6

The elephant in the room here is that you can pay to win in any game by buying a monitor with higher reftesh rate and use a larger GPU that uses more electricity to have 2x more time to react. Fortunately for us humans that seems to stop at 120Hz because most games can't even hold that at a steady rate with a 3090. Now whether a 300+W gaming device is interesting in the long run will be answered this year by your ele…

lol -- Most CS:GO top level players are playing on 240hz, and getting close to 500+ fps.

Also, higher refresh will give skilled players an advantage, but it's def not pay to win.

Re: LatencyFleX: A new approach to game latency reduction

#12

Post by formerly_proven »

bullen wrote: post #6

The elephant in the room here is that you can pay to win in any game by buying a monitor with higher reftesh rate and use a larger GPU that uses more electricity to have 2x more time to react. Fortunately for us humans that seems to stop at 120Hz because most games can't even hold that at a steady rate with a 3090. Now whether a 300+W gaming device is interesting in the long run will be answered this year by your ele…

Lots of multiplayer games intentionally implement low-vis, low-contrast environments (mud-colored players in mud-colored environments) which is why things like Digital Vibrance and "Black Enhancers" are so popular. Arguably the competitive advantage of those, tuned to the game [1], exceeds everything else once you've done the basics (120+ Hz, normal-acting hardware).

[1] In a particular game I discovered that abusing the R/G/B controls into giving you something that looks almost like one of those colorblind simulations in normal conditions would give you a massive advantage to the point of most players calling hacks.

Re: LatencyFleX: A new approach to game latency reduction

#14

Post by hffftz »

formerly_proven wrote: post #10
hffftz wrote: post #9

Earlier quoted context omitted.

> If you want to add usb, you buy an extra chip. Do you know how many chips are in a cable modem/router combo?

1 or 2, depends on the kind of modem. VDSL2+ modems might have three, though one of those is the line driver which is zero-delay for the purposes of a computer.

I've seen many more chips last time I opened one....

Re: LatencyFleX: A new approach to game latency reduction

#15

Post by mat0 »

bullen wrote: post #6

The elephant in the room here is that you can pay to win in any game by buying a monitor with higher reftesh rate and use a larger GPU that uses more electricity to have 2x more time to react. Fortunately for us humans that seems to stop at 120Hz because most games can't even hold that at a steady rate with a 3090. Now whether a 300+W gaming device is interesting in the long run will be answered this year by your ele…

By that logic, every sports player that uses high quality gear is "paying to win". Is Nadal winning solely based on the quality of his racquet? Of course not. Would he play with a basic or low quality one? Absolutely not. What's wrong using the best gear possible?

I don't know where'd you get this notion that it stops at 120hz. It's been proven again and again that even with monitors with low refresh rate you still get a better experience by having more fps available. Better so when you have both the frames and the refresh rate in your monitor.

Re: LatencyFleX: A new approach to game latency reduction

#16

Post by zamadatix »

moffkalast wrote: post #13
willis936 wrote: post #2

Impressive stuff. Especially cool to see it licensed with Apache. I hope Godot integrates it.

I'm sure Godot will integrate it in version 4.1... when it comes out in 10 years.

I'm all for poking fun but this just seems excessive as Godot isn't even 10 years old.

Re: LatencyFleX: A new approach to game latency reduction

#17

Post by billconan »

> The cause of Bufferbloat was that previously, congestion control relied on packet loss, which was a signal that the buffer is full.

I couldn't understand "congestion control relied on packet loss"? could somebody explain? Thanks!

does it mean "congestion control is triggered by the packet loss event, which is a signal for buffer being full"?

Re: LatencyFleX: A new approach to game latency reduction

#18

Post by duped »

snarfy wrote: post #8
hffftz wrote: post #5

Earlier quoted context omitted.

How can you get input lag of 20ms? do you have to slow down your code? I only implied it was network lag because it was so high.

There are a variety of factors that add up to many ms of lag. USB and HDMI are a few that come to mind. USB is incredibly complex when compared to e.g. ps/2. If you are building an embedded board like rasberry pi and you want to add ps/2, you just add a couple pins. If you want to add usb, you buy an extra chip.

Many CPUs have USB support. Pin count also doesn't correlate to latency, what matters is the minimum buffer size and transfer speed.

USB can beat PS/2 for latency without issue.

Re: LatencyFleX: A new approach to game latency reduction

#19

Post by ben-schaaf »

hffftz wrote: post #9
snarfy wrote: post #8

Earlier quoted context omitted.

There are a variety of factors that add up to many ms of lag. USB and HDMI are a few that come to mind. USB is incredibly complex when compared to e.g. ps/2. If you are building an embedded board like rasberry pi and you want to add ps/2, you just add a couple pins. If you want to add usb, you buy an extra chip.

> If you want to add usb, you buy an extra chip. Do you know how many chips are in a cable modem/router combo?

Modems/routers don't use polling nor do they need debouncing. The default USB polling rate is 125Hz, which is already 8ms of latency. Debouncing depends on the switch and is generally a couple milliseconds as well.

Re: LatencyFleX: A new approach to game latency reduction

#20

Post by zamadatix »

hffftz wrote: post #5
ishitatsuyuki wrote: post #4

Earlier quoted context omitted.

Input lag has nothing to do with network ping. Input lag is the time between you perform the action and the computer shows that on screen. It depends on your frame rate, refresh rate, and peripheral polling rate, as well as how good the game schedules things (which is what LatencyFleX tries to optimize). Network ping on the other hand is often hidden away. Whether you are on 2ms ping or 100ms ping, the bullet always…

How can you get input lag of 20ms? do you have to slow down your code? I only implied it was network lag because it was so high.

Input lag is the period between input and output, not just the time to poll the input. E.g. on 250 Hz standard mice just polling the mouse will average 2 ms input lag with 2 ms jitter and that's before you've even done anything with the input. If you don't have a high refresh rate VRR gaming display and don't want tearing the same repeats, e.g. 60hz would be 8.3 +- 8.3. That's halfway to 20 and we haven't even gotten to delays from the game code where you can choose things like triple buffering for higher FPS at the cost of another frame of latency. Input lag can also include output to the monitor and delay from the monitor depending how it's being measured.

In this case it's more about the rendering pipeline input lag so the USB polling delay and the monitor output delay aren't counted, the swapchain delay to prevent tearing or trading latency/FPS are though and then you have to add in your actual game still.

Post reply on HN