m_rawinput 1/0 - Testing for input lag in CS:GO

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
Spyfluen
Posts: 3
Joined: 30 Mar 2014, 04:27

m_rawinput 1/0 - Testing for input lag in CS:GO

Post by Spyfluen » 30 Mar 2014, 04:57

m_rawinput 1 should in theory only be a good thing to enable in all games, if you want exact and consistent 1:1 mouse-movement.

However,in the past months there have been a lot of controversy regarding m_rawinput in CS:GO. Many CS:GO gamers believe that m_rawinput is faulty implented in CS:GO, and therefore many of the pro gamers have switched from m_rawinput 1 to 0. By switching to 0 (OFF), many CS:GO gamers say they feel more responsive mouse movement compared to m_rawinput ON (1).

It all started with this post on reddit: http://www.reddit.com/r/GlobalOffensive ... ut_faulty/

Some of the reports are quouted here:
"ok, so i think OP is on to something. with m_rawinput 0 aiming seems smoother and more responsive. i don't think m_rawinput 1 applies acceleration, but it does something which is remedied by turning rawinput off. i will be using m_rawinput 0 in future."
"I do think there is something odd with ri (rawinput, red.) 1 on CSGO : the best way I could describe it is a small delay between the hand movement and the actual move on the screen."
"I found that raw input has a delay for me"
These reports are very strange and implies that rawinput may not function as intended in CS:GO. It may add some kind of unintended input lag.

Mouse expert "Skylit" from overclock.net does his best to explain why rawinput in theory should be superior to normal input:

http://www.overclock.net/t/1405271/rega ... timization
Raw input: This is API that buffers mouse movement independent of frame rate. Traditionally, games like counter strike, early quake, ut. etc.. rendered mouse input by center grab repositioning or WM_MOUSEMOVE. Raw input in layman's terms reads information from your mouse directly (inc. polling) and translates 1:1 DPI settings to game. Mouse fix or windows settings need not apply.

Controversy over added input latency or smoothing effect reported by users: Raw input regardless of game engine will almost always buffer polled rate faster than that of the average frame rate you pull in game. There may be an “unconnected” feeling for many users as movement is no longer based on in-game fps.

The only time where this is not the case is if you happen to use a lower polled mouse rate and render in-game frames at or above your buffered setting.
________________

Now I'm a big fan of this site and these forums, and as I've already seen blurbuster-user 'sharknice' make awesome tests of input lag in CS:GO (multi-core-rendering vs single-core rendering) here: http://forums.blurbusters.com/viewtopic.php?f=10&t=325 , I was hoping that he or any other skilled technical guy maybe could do some input-lag test for m_rawinput 1/0 in CS:GO. Such test could either confirm or deny the odd idea that rawinput is faulty implented in CS:GO. As every competetive Counter-Strike gamer strives for zero input lag, such tests could be very, very helpful for the CS:GO community and maybe force Valve to look into a possible underlying bug with the m_rawinput command.

The test should ideally be performed with an already fast high-refresh monitor (120 HZ minimum) and a mouse with 1000 HZ polling rate.

I really hope someone here would do such tests, as I myself don't have the necessary knowledge nor equipment to do such tests. I would be so thankful, and I know many other CS:GO gamers would be extremely interested in such tests.

Cheers! Crossing fingers.

User avatar
Chief Blur Buster
Site Admin
Posts: 11648
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: m_rawinput 1/0 - Testing for input lag in CS:GO

Post by Chief Blur Buster » 30 Mar 2014, 11:11

Spyfluen wrote:m_rawinput 1 should in theory only be a good thing to enable in all games, if you want exact and consistent 1:1 mouse-movement.

However,in the past months there have been a lot of controversy regarding m_rawinput in CS:GO. Many CS:GO gamers believe that m_rawinput is faulty implented in CS:GO, and therefore many of the pro gamers have switched from m_rawinput 1 to 0. By switching to 0 (OFF), many CS:GO gamers say they feel more responsive mouse movement compared to m_rawinput ON (1).

It all started with this post on reddit: http://www.reddit.com/r/GlobalOffensive ... ut_faulty/

Some of the reports are quouted here:
"ok, so i think OP is on to something. with m_rawinput 0 aiming seems smoother and more responsive. i don't think m_rawinput 1 applies acceleration, but it does something which is remedied by turning rawinput off. i will be using m_rawinput 0 in future."
"I do think there is something odd with ri (rawinput, red.) 1 on CSGO : the best way I could describe it is a small delay between the hand movement and the actual move on the screen."
"I found that raw input has a delay for me"
These reports are very strange and implies that rawinput may not function as intended in CS:GO. It may add some kind of unintended input lag.

Mouse expert "Skylit" from overclock.net does his best to explain why rawinput in theory should be superior to normal input:

http://www.overclock.net/t/1405271/rega ... timization
Raw input: This is API that buffers mouse movement independent of frame rate. Traditionally, games like counter strike, early quake, ut. etc.. rendered mouse input by center grab repositioning or WM_MOUSEMOVE. Raw input in layman's terms reads information from your mouse directly (inc. polling) and translates 1:1 DPI settings to game. Mouse fix or windows settings need not apply.

Controversy over added input latency or smoothing effect reported by users: Raw input regardless of game engine will almost always buffer polled rate faster than that of the average frame rate you pull in game. There may be an “unconnected” feeling for many users as movement is no longer based on in-game fps.

The only time where this is not the case is if you happen to use a lower polled mouse rate and render in-game frames at or above your buffered setting.
________________

Now I'm a big fan of this site and these forums, and as I've already seen blurbuster-user 'sharknice' make awesome tests of input lag in CS:GO (multi-core-rendering vs single-core rendering) here: http://forums.blurbusters.com/viewtopic.php?f=10&t=325 , I was hoping that he or any other skilled technical guy maybe could do some input-lag test for m_rawinput 1/0 in CS:GO. Such test could either confirm or deny the odd idea that rawinput is faulty implented in CS:GO. As every competetive Counter-Strike gamer strives for zero input lag, such tests could be very, very helpful for the CS:GO community and maybe force Valve to look into a possible underlying bug with the m_rawinput command.

The test should ideally be performed with an already fast high-refresh monitor (120 HZ minimum) and a mouse with 1000 HZ polling rate.

I really hope someone here would do such tests, as I myself don't have the necessary knowledge nor equipment to do such tests. I would be so thankful, and I know many other CS:GO gamers would be extremely interested in such tests.

Cheers! Crossing fingers.
Firstly, welcome to Blur Busters Forums!

Secondly, you bring up some really interesting test scenarios that is worthwhile testing for! sharknice also created our Blur Busters Mouse Guide at http://www.blurbusters.com/mouse-guide as well

What you describe is definitely worthy of testing for!

One potential factor to account for, other than raw input, is mouse jitter - Basically, mouse position reports that are randomly arriving late, rather than on time. This could be caused by many factors, such as variable USB latency (hubs, etc) but I wonder if raw input improves or worsens jitter. That would interfere with aiming, even if average latency is better. For example, 1ms less latency but much worse jitter (provided the jitter is bad enough), might actually become worse than 1ms more latency but zero jitter. You rather not have either, but there might be a pick-your-poison effect occuring. I don't know. But this is one theory, I am offering - that there might be a tradeoff effect occuring. Where some gamers are hating one tradeoff versus the other tradeoff. Again, this is a theory only, and needs to be determined.

P.S. You sound like you know a few smart people in the game world! So I have a question. Do you know some "Blur Busters savvy people" who also works for other websites whether small hobbyist sites, or larger such as AnandTech, TomsHardware, etc? I'm looking for freelance article writers with the "Blur Busters" mindset, to help output more interesting "Blur Busters league" articles, at a more rapid pace. We know a lot of readers are hungry for more articles, and Chief Blur Buster (me) can only write so much.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

Spyfluen
Posts: 3
Joined: 30 Mar 2014, 04:27

Re: m_rawinput 1/0 - Testing for input lag in CS:GO

Post by Spyfluen » 30 Mar 2014, 13:51

Hey Chief, thanks for the welcome.

Definitely an interesting point about mouse jitter - rawinput in CS:GO might, as you say, improve or worsen it.

Apparently there are two ways for a program to read raw input data.
There are two ways to read the raw data: the unbuffered (or standard) method and the buffered method. The unbuffered method gets the raw data one RAWINPUT structure at a time and is adequate for many HIDs. Here, the application calls GetMessage to get the WM_INPUT message. Then the application calls GetRawInputData using the RAWINPUT handle contained in WM_INPUT. For an example, see Doing a Standard Read of Raw Input.

In contrast, the buffered method gets an array of RAWINPUT structures at a time. This is provided for devices that can produce large amounts of raw input. In this method, the application calls GetRawInputBuffer to get an array of RAWINPUT structures. Note that the NEXTRAWINPUTBLOCK macro is used to traverse an array of RAWINPUT structures. For an example, see Doing a Buffered Read of Raw Input.
-http://msdn.microsoft.com/en-us/library ... s.85).aspx

It sounds to me that the unbuffered method might be superior in terms of input lag (or mouse jitter) compared to the buffered method, but I got no clue really.

On the off-topic: Sorry, but unfortunately I don't personally know any blur-buster savy people outside these forums :/.

User avatar
Chief Blur Buster
Site Admin
Posts: 11648
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: m_rawinput 1/0 - Testing for input lag in CS:GO

Post by Chief Blur Buster » 31 Mar 2014, 17:33

Spyfluen wrote:It sounds to me that the unbuffered method might be superior in terms of input lag (or mouse jitter) compared to the buffered method, but I got no clue really.
Yes, the unbuffered method can be more easily timestamp (sub-millisecond accurate) based on the arrival of the mouse reports, so that the game engine can eliminate mouse jitter based on that information.

Now, the buffered method MIGHT be more accurate in certain cases *if* the game engine compensate AND the structures provides some method of timestamping each mouse report arrival, so that the game engine can use that info.

Thanks for your suggestions!
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

User avatar
sharknice
Posts: 295
Joined: 23 Dec 2013, 17:16
Location: Minnesota
Contact:

Re: m_rawinput 1/0 - Testing for input lag in CS:GO

Post by sharknice » 01 Apr 2014, 16:47

I loaded up an empty bot game and tried toggling it on and off. I was getting around 600 fps and it didn't really seem to make a difference, then I capped my fps to 144 and It seemed like 0 was more responsive than 1, but it was hard to tell.
I'm not really sure how to test this by anything other than feel.

User avatar
Chief Blur Buster
Site Admin
Posts: 11648
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: m_rawinput 1/0 - Testing for input lag in CS:GO

Post by Chief Blur Buster » 01 Apr 2014, 20:04

sharknice wrote:I loaded up an empty bot game and tried toggling it on and off. I was getting around 600 fps and it didn't really seem to make a difference, then I capped my fps to 144 and It seemed like 0 was more responsive than 1, but it was hard to tell.
I'm not really sure how to test this by anything other than feel.
Very interesting!
Uncapped situations -- either 0 or 1 works well;
Capped situations -- 0 seems to work better;

I wonder if the use of 0 during fps_max 144fps creates 6.9ms of mouse position jittering. While uncapped situations, there would be only 1/600sec of mouse jitter (less than 2ms) and this becomes negligible. I'm wondering how 1 versus 0 behaves in this regards. I wonder if this will show in the Blur Busters high speed camera input lag testing technique.

sharknice, it might also apply to mouse button triggering. Are you able to test the capped situation, of 1 versus 0, with the high speed camera technique? We might need 20-30 passes in order to come up with conclusions, since the display refresh cycle aliasing will need to be averaged out, so that sub-refresh-cycle latency differences start to show up much more clearly. If this is too time consuming to test, add it to a TODO list next time you do a run of latency tests...
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

Spyfluen
Posts: 3
Joined: 30 Mar 2014, 04:27

Re: m_rawinput 1/0 - Testing for input lag in CS:GO

Post by Spyfluen » 04 Apr 2014, 06:12

As far as I know the m_rawinput command controls how CS:GO gets all mouse data, not just movement, but also mouse-button-clicks.

So yeah, I guess you could test for input lag differences (m_rawinput 1/0) by using that high speed camera technique.

peleh
Posts: 11
Joined: 07 Apr 2014, 00:01

Re: m_rawinput 1/0 - Testing for input lag in CS:GO

Post by peleh » 08 Apr 2014, 02:21

The problem with CS GO is that with m_rawinput 0 you get diferent sensitivities based on FPS, which forces you to cape the fps to your minimum stable fps to keep it controled.

With m_rawinput 1 its independent, but you get a wierd feeling while using an 1000hz mouse. One thing I tested here was by lowering the hz of the mouse to below the fps, so 125hz, and the movement got better.

Eventualy I tested this program: http://www.hltv.org/blog/6748-easier-raw-input-method and didn't looked back once.

Post Reply