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! (:
RawInput: final solution?
Re: RawInput: final solution?
Equipment isn't much so expensive. Used Nikon 1 series (Nikon 1 J1 for example) can be bought for less than $100.
I'm not interested in cs:go and have no time to test it.
I'm not interested in cs:go and have no time to test it.
Re: RawInput: final solution?
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.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.
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.
- lexlazootin
- Posts: 1251
- Joined: 16 Dec 2014, 02:57
Re: RawInput: final solution?
Do you just put a wire attached to both sides of the switch and have a battery somewhere in that connection?Q83Ia7ta wrote:Equipment isn't much so expensive. Used Nikon 1 series (Nikon 1 J1 for example) can be bought for less than $100.
Re: RawInput: final solution?
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.lexlazootin wrote:Do you just put a wire attached to both sides of the switch and have a battery somewhere in that connection?Q83Ia7ta wrote:Equipment isn't much so expensive. Used Nikon 1 series (Nikon 1 J1 for example) can be bought for less than $100.
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).
Re: RawInput: final solution?
I don't know this. It doesn't feel more delayed to me - certainly not much more.As most of you already know, m_rawinput 1 in cs go feels much more delayed compared to m_rawinput 0.
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.
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.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.
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.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.