RawInput: final solution?

Everything about latency. Tips, testing methods, mouse lag, display lag, game engine lag, network lag, whole input lag chain, VSYNC OFF vs VSYNC ON, and more! Input Lag Articles on Blur Busters.
Post Reply
nicolovbg
Posts: 1
Joined: 13 Sep 2016, 11:46

RawInput: final solution?

Post by nicolovbg » 13 Sep 2016, 11:55

Hello everybody!

As most of you already know, m_rawinput 1 in cs go has no packet loss, but feels much more delayed compared to m_rawinput 0.

This topic has been discussed a lot, even researched, and the result of this "research" is what we all know as Rinput, implemented in SourceGL program.

Anyway, here I want to talk about the click latency difference between m_rawinput 0 and m_rawinput 1, as I haven't seen any threads mentioning this problem.

Unfortunately, I don't have any equipment to properly test the difference, yet I can say for sure, for myself at least, that m_rawinput 0 is far behind in terms of click latency.

I imagine the test as recording a video with 1000 FPS camera with LED connected to the mouse button and the display in the same frame. In this situation you can easily measure the delay.

I would love to see some responses from tech gurus here, whether they have noticed the delay, what they think about the problem and how it can be solved. Any feedback is greatly appreciated, let's discuss it! (:

Q83Ia7ta
Posts: 761
Joined: 18 Dec 2013, 09:29

Re: RawInput: final solution?

Post by Q83Ia7ta » 13 Sep 2016, 13:05

Equipment isn't much so expensive. Used Nikon 1 series (Nikon 1 J1 for example) can be bought for less than $100.
phpBB [video]


I'm not interested in cs:go and have no time to test it.

Sparky
Posts: 682
Joined: 15 Jan 2014, 02:29

Re: RawInput: final solution?

Post by Sparky » 13 Sep 2016, 19:14

nicolovbg wrote:Anyway, here I want to talk about the click latency difference between m_rawinput 0 and m_rawinput 1, as I haven't seen any threads mentioning this problem.
That was something flood tested(with better methodology than a high speed camera), IIRC there was no difference in latency, but there was some weird behavior with dropped samples.
Here's the data he collected: https://docs.google.com/spreadsheets/d/ ... 1384834239

And a couple relevant threads:
blurbusters thread on input lag measurements.
OCN thread on rawinput quirks.

User avatar
lexlazootin
Posts: 1251
Joined: 16 Dec 2014, 02:57

Re: RawInput: final solution?

Post by lexlazootin » 13 Sep 2016, 23:07

Q83Ia7ta wrote:Equipment isn't much so expensive. Used Nikon 1 series (Nikon 1 J1 for example) can be bought for less than $100.
Do you just put a wire attached to both sides of the switch and have a battery somewhere in that connection?

Sparky
Posts: 682
Joined: 15 Jan 2014, 02:29

Re: RawInput: final solution?

Post by Sparky » 14 Sep 2016, 06:14

lexlazootin wrote:
Q83Ia7ta wrote:Equipment isn't much so expensive. Used Nikon 1 series (Nikon 1 J1 for example) can be bought for less than $100.
Do you just put a wire attached to both sides of the switch and have a battery somewhere in that connection?
Depends on how the switch is wired, but you wouldn't need a battery, just use the power rails that are already there. Most of the time all you'd need to add is the LED in series with a current limiting resistor, which you connect to the switched side of the switch and the opposite rail as the unswitched side of the switch. You only need something more complicated when neither side of the switch is directly connected to a power rail, in which case you need to figure out if some kind of multiplexing is going on.

As for using a battery to power your LED, you still need to understand the circuit well enough to ensure it doesn't impact the rest of the circuit, because it's possible to bypass the switch or fry something with the battery voltage if you connect it wrong(like put the diode in the wrong way around).

stirner
Posts: 74
Joined: 07 Aug 2014, 04:55

Re: RawInput: final solution?

Post by stirner » 17 Sep 2016, 06:57

As most of you already know, m_rawinput 1 in cs go feels much more delayed compared to m_rawinput 0.
I don't know this. It doesn't feel more delayed to me - certainly not much more.

The only thing I've considered is possible (or, well, not impossible) in that regard is that raw input data in CS:GO gets worked into frames at an earlier point in the frame creation process (gathering input, game state, simulating world, [...], rendering frame), so it could be that there's a slight latency difference there. In that case it would be more noticeable the longer that process takes, i. e. the lower your framerate. I've never tested for this due to lack of an accurate enough measuring setup. My camera tests (and AFAIR flood's and Sparky's arduino tests) have yielded no appreciable difference between the two.
This topic has been discussed a lot, even researched, and the result of this "research" is what we all know as Rinput, implemented in SourceGL program.
RInput is and old old piece of code. One that showed the same packet loss behaviour standard input exhibits at that. The one implemented in "SourceGL" was actually updated by flood and whoever to stop doing that. So yeah, if there really is a difference in how (when) CS:GO implements input gathering with m_rawinput 1, RInput could be a solution for that. I have played a fair bit and couldn't notice a difference between the two. This would need blind tests I have never been bothered enough to do. I'm perfectly happy with m_rawinput 1.
Anyway, here I want to talk about the click latency difference between m_rawinput 0 and m_rawinput 1, as I haven't seen any threads mentioning this problem.
As Sparky said, there was no noteworthy difference when flood tested for this. While this would also conclude that there's no input latency difference altogether between m_rawinput 1 and 0, it could as said above have to do with framerate, or even specific steps of the frame creation process taking more time under certain cirucmstances. All of that is speculation and not really gameplay relevant either way.

Post Reply