csgo m_rawinput 0 drops samples - Overclock.net - An Overclocking Community

Forum Jump: 

csgo m_rawinput 0 drops samples

Reply
 
Thread Tools
post #1 of 285 (permalink) Old 03-09-2015, 03:16 AM - Thread Starter
lololol
 
qsxcv's Avatar
 
Join Date: Feb 2014
Posts: 4,198
Rep: 362 (Unique: 150)
many people have reported the raw input in csgo feels delayed/processed/smoothed/whatever. i don't have anything to say about those claims yet, though finalmouse-jude posted a few days ago implying that they have found some issue with m_rawinput 1.

but anyway i have found a problem with m_rawinput 0 that i felt people should know about

https://www.youtube.com/watch?v=hwVjDNmBVos

my teensy behaves as a 1000hz mouse. i've coded it to do nothing except move the cursor back and forth between two points
the code is very simple and basically:
Code:
while (!SW_READ) { //while the slider is switched on
    usb_mouse_move(10,-3,0);
    usb_mouse_move(-10,3,0);
}

as you can see in beginning of the video, my polling is very stable and there is no dropped frames anywhere. the windows cursor bounces back and forth between two points as expected.

yet in csgo, with m_rawinput 0, the screen randomly drifts around instead of just quickly bouncing between two angles. this is a clear sign that some movement data is being dropped.
with m_rawinput 1, the screen bounces between two points as expected.

the same behavior occurs with 500hz.
this is unrelated to how, with m_rawinput 0, you can sometimes move the windows cursor too fast and clip against the edge of the screen. i'm only moving the cursor a tiny amount and the problem is independent of resolution.
it also seems to be independent of the framerate
i have no idea what's going on

trying rinput.exe now...

welp
using rinput.exe and m_rawinput 0 gives the same issue

too busy to check forums as regularly
pm me if i forget to respond
qsxcv is offline  
Sponsored Links
Advertisement
 
post #2 of 285 (permalink) Old 03-09-2015, 03:49 AM
Linux Lobbyist
 
Harrywang's Avatar
 
Join Date: Jan 2012
Posts: 268
Rep: 3 (Unique: 3)
Quote:
Originally Posted by qsxcv View Post

many people have reported the raw input in csgo feels delayed/processed/smoothed/whatever. i don't have anything to say about those claims yet, though finalmouse-jude posted a few days ago implying that they have found some issue with m_rawinput 1.

but anyway i have found a problem with m_rawinput 0 that i felt people should know about

https://www.youtube.com/watch?v=hwVjDNmBVos

my teensy behaves as a 1000hz mouse. i've coded it to do nothing except move the cursor back and forth between two points
the code is very simple and basically:
Code:
while (!SW_READ) { //while the slider is switched on
    usb_mouse_move(10,-3,0);
    usb_mouse_move(-10,3,0);
}

as you can see in beginning of the video, my polling is very stable and there is no dropped frames anywhere. the windows cursor bounces back and forth between two points as expected.

yet in csgo, with m_rawinput 0, the screen randomly drifts around instead of just quickly bouncing between two angles. this is a clear sign that some movement data is being dropped.
with m_rawinput 1, the screen bounces between two points as expected.

the same behavior occurs with 500hz.
this is unrelated to how, with m_rawinput 0, you can sometimes move the windows cursor too fast and clip against the edge of the screen. i'm only moving the cursor a tiny amount and the problem is independent of resolution.
it also seems to be independent of the framerate
i have no idea what's going on

trying rinput.exe now...

welp
using rinput.exe and m_rawinput 0 gives the same issue

Awesome find. This just completely confirms my speculation that rinput and m_rawinput 0 is insanely inferior to m_raw input 1. I've been trying all 3 the past month and find that rawinput 1 is just much more accurate and "raw"
Harrywang is offline  
post #3 of 285 (permalink) Old 03-09-2015, 04:08 AM - Thread Starter
lololol
 
qsxcv's Avatar
 
Join Date: Feb 2014
Posts: 4,198
Rep: 362 (Unique: 150)
Quote:
Originally Posted by Harrywang View Post

Awesome find. This just completely confirms my speculation

no it doesn't... but the important thing to take away is that even if m_rawinput 1 has some issue, rinput.exe and/or m_rawinput 0 isn't a perfect solution

still have to wait and see what the finalmouse guys found... but i guess, as they are a company, they are hesitant to post anything potentially controversial without first being completely sure of it

too busy to check forums as regularly
pm me if i forget to respond
qsxcv is offline  
Sponsored Links
Advertisement
 
post #4 of 285 (permalink) Old 03-09-2015, 04:18 AM
New to Overclock.net
 
HAGGARD's Avatar
 
Join Date: Jun 2013
Posts: 657
Rep: 56 (Unique: 44)
The only thing I can come up with is cursor reset rate (framerate) leading to some dropped counts. An old issue with cursor-based input that Valve added m_mousethread_sleep for in 1.6. But you said it's independent of framerate and on average there are more "right" counts missed (which could have to do something with timing specifics as well though). And since happens with RInput.exe (which shows odd behaviour where the in-game cursor can still affect the view angle, but otherwise behaves just as you'd raw input expect to behave) it maybe really is something in the standard input code that isn't used with the m_rawinput 1 model.

Is your Windows resolutive DPI at standard (100%)?
HAGGARD is offline  
post #5 of 285 (permalink) Old 03-09-2015, 04:20 AM
Mouse reviewer
 
Ino.'s Avatar
 
Join Date: Sep 2011
Posts: 3,092
Rep: 405 (Unique: 238)
I think what this shows us is that the feeling of something that is technically worse ( in some regard) is better to some for reasons unknown. I have had this suspicion for a while because people sometimes completely contradict each other with cursor feeling. Some find mouse x to be awesomly raw and mouse y lagging and others feel it the other way around.
Ino. is offline  
post #6 of 285 (permalink) Old 03-09-2015, 04:44 AM - Thread Starter
lololol
 
qsxcv's Avatar
 
Join Date: Feb 2014
Posts: 4,198
Rep: 362 (Unique: 150)
Quote:
Originally Posted by HAGGARD View Post

The only thing I can come up with is cursor reset rate (framerate) leading to some dropped counts. An old issue with cursor-based input that Valve added m_mousethread_sleep for in 1.6. But you said it's independent of framerate and on average there are more "right" counts missed (which could have to do something with timing specifics as well though). And since happens with RInput.exe (which shows odd behaviour where the in-game cursor can still affect the view angle, but otherwise behaves just as you'd raw input expect to behave) it maybe really is something in the standard input code that isn't used with the m_rawinput 1 model.

Is your Windows resolutive DPI at standard (100%)?
thats what i'm thinking of as well. when the cursor gets reset to the screen center, there could be a brief period where any mouse data is ignored

the video is only a brief sample. overall i don't notice any asymmetry.

i'm not sure about the impact of framerate but i'll try to gather some statistics tomorrow.

my windows is 6/11, enhance pointer off, no accel fixes

too busy to check forums as regularly
pm me if i forget to respond
qsxcv is offline  
post #7 of 285 (permalink) Old 03-09-2015, 04:52 AM
New to Overclock.net
 
HAGGARD's Avatar
 
Join Date: Jun 2013
Posts: 657
Rep: 56 (Unique: 44)
Oh, I see. Thought it was always wandering to the left.

With resolutive DPI I meant this http://images.pcworld.com/images/article/2011/11/sizewindow-5232079.png
At non-default you don't get 1:1 count to pixel AFAIK. You could go into 1.6 and compare m_rawinput 1 vs 0 there with m_mousethread_sleep at different values as well.

I'm currently writing a macro to test this myself.
HAGGARD is offline  
post #8 of 285 (permalink) Old 03-09-2015, 04:55 AM - Thread Starter
lololol
 
qsxcv's Avatar
 
Join Date: Feb 2014
Posts: 4,198
Rep: 362 (Unique: 150)
Quote:
Originally Posted by Ino. View Post

I think what this shows us is that the feeling of something that is technically worse ( in some regard) is better to some for reasons unknown. I have had this suspicion for a while because people sometimes completely contradict each other with cursor feeling. Some find mouse x to be awesomly raw and mouse y lagging and others feel it the other way around.
yea the psychology of this stuff is really not simple

for instance, someone who tries a really good mouse with an accurate stable sensor may interpret the mouse's smooth response as the artifact of processing which he had experienced in previous mice.

too busy to check forums as regularly
pm me if i forget to respond
qsxcv is offline  
post #9 of 285 (permalink) Old 03-09-2015, 04:57 AM - Thread Starter
lololol
 
qsxcv's Avatar
 
Join Date: Feb 2014
Posts: 4,198
Rep: 362 (Unique: 150)
Quote:
Originally Posted by HAGGARD View Post

Oh, I see. Thought it was always wandering to the left.

With resolutive DPI I meant this http://images.pcworld.com/images/article/2011/11/sizewindow-5232079.png
At non-default you don't get 1:1 count to pixel AFAIK. You could go into 1.6 and compare m_rawinput 1 vs 0 there with m_mousethread_sleep at different values as well.

I'm currently writing a macro to test this myself.
*** that setting affects mouse sens in windows? i've never touched that and my monitors are not really high-res so it's probably at default. ill check to be sure tomorrow but it shouldnt really matter

too busy to check forums as regularly
pm me if i forget to respond
qsxcv is offline  
post #10 of 285 (permalink) Old 03-09-2015, 05:07 AM
New to Overclock.net
 
HAGGARD's Avatar
 
Join Date: Jun 2013
Posts: 657
Rep: 56 (Unique: 44)
Yeah, has to interpolate whole counts to fit awkward pixel adjustments. Should affect how many counts you need before the cursor moves by "one" pixel, which obviously holds implications for standard input. If you haven't touched it, it is at default.

That aside, I am seeing the exact same results you do with my macro. Very unlikely that our setups share some complex timing issues in the hardware or whatever. My macro also executes at 1,5ms rather than 1ms. It's either the inherent issue of cursor reset rate or input code nonsense in GO. Will test 1.6 now.

O.K.: Same behaviour in 1.6 with standard input as in GO, regardless of m_mousethread_sleep setting. And with m_rawinput 1, I get a constant travel to the right. What the f*** is Valve doing.

O.K.2: Forgot the -mousethread launch option.
Quote:
alfred-valve commented on 21 Feb 2013

Okay, next release will add a "-mousethread" command line option and a "m_mousethread_sleep" cvar. If "-mousethread" is set then on Windows (and only windows) we will spawn a thread to scan for mouse input every m_mousethread_sleep milliseconds, the main game thread then picks it up when needed. This should better capture micro movements that may be lost due to the frame rate of the main engine (or dips in it).
I'd like feedback on how it feels (compared to not using the param and also using m_rawinput 1).

Changing m_mousethread_sleep changes how erratic the behaviour is. But it doesn't get rid of it at any value. But it does suggest that cursor reset rate (which the m_mousethread_sleep command controls independent of framerate) does affect how often count data is lost.

Edit3: Pretty clear for me now. Counts being dropped with standard input comes down to the inherent issue of cursor reset time of the engine vs. input receive time in Windows. Since framerate determines cursor reset rate, higher framerate should lead to more missed counts. Both increasing the framerate and forcing cursor reset rate higher with m_mousethread_sleep showed an increase in random view angle deviation for me (at 1000fps m_mousethread_sleep 1 I was basically doing 360s).

m_rawinput in GO works as intended, i.e. non cursor-based, so the inherent cursor reset problem doesn't exist.
m_rawinput 1.6 is bugged. Constantly registers more right than left counts on the X axis.
RInput.exe does not seem to work properly in GO. The engine will still refer to cursor movement (WM_MOUSEMOVE) for buffered count data. I think injecting RInput in GO creates another buffer and so you essentially read from two. Or something. Very strange. Safe to say though: Stay away.
HAGGARD is offline  
Reply

Quick Reply
Message:
Options

Register Now

In order to be able to post messages on the Overclock.net - An Overclocking Community forums, you must first register.
Please enter your desired user name, your email address and other required details in the form below.
User Name:
If you do not want to register, fill this field only and the name will be used as user name for your post.
Password
Please enter a password for your user account. Note that passwords are case-sensitive.
Password:
Confirm Password:
Email Address
Please enter a valid email address for yourself.
Email Address:

Log-in



Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may post new threads
You may post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off