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.
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.