CSGO is one of the the biggest competitive fps and aim is one of the most important aspects of it, unfortunately the game's mouse input handling is not perfect.
Years ago, over at OCN it was discovered that the windows pointer method (m_rawinput 0) suffers from data packet loss, common problem to ANY GAME that uses that method.
On the other hand, CSGO's implementation of raw input (m_rawinput 1) does indeed have up to ~2ms of added input latency compared to the windows pointer method, depending on the framerate.
Here are links to the thread and the spreadsheet with measurements made with a microsecond accurate testing rig. (yes microsecond not millisecond like 1000fps cameras)
Thread : https://www.overclock.net/forum/375-mice/1545382-csgo-m_rawinput-0-drops-samples-25.html#post24519425 (open the spoilers in the faq post, formatting got ruined because of the forum framework migration)
Spreadsheet: https://docs.google.com/spreadsheets/d/1cktehkalPAbJ5014jL-Vtg3YmGXmNTnAZy5CAQ-Zpkk/edit#gid=1426052600
This problem got solved by OCN community members qsxcv and VolsandJezuz with rinput 1.44 : a custom raw input injector modded from rinput 1.31, an old program used to enable raw input in games that lacked the feature.
rinput 1.31 unfortunately had the same packet loss problem that the windows pointer method has, so it got improved to be the PERFECT raw input solution for CSGO and many other games, devoid of ANY LAG or PACKET LOSS.
Now with the trusted mode update we cannot use rinput 1.44 anymore. At first it worked only in untrusted mode, now not even there. (not that you'd want to play untrusted anyway)
So it would be good if the devs would either: whitelist rinput 1.44 so that it can be used again, or better make the code native to CSGO adding an m_rawinput 2 option that uses the rinput method to achieve perfect lag free raw input.
The second option would be ideal if worried about potential exploits and is overall more desirable since it wouldn't require launching the game with a batch file.
Technicalities:
The windows pointer method loses mouse packets because of the way it works.
In-game mouse movement is achieved by looking at how much the windows pointer moves from the center of the screen on the underlying desktop and then resetting it to the center every frame.
The number of pixels from the center of the screen gets multiplied by the sensitivity value(s) and that tells the game how many degrees to move the camera (crosshair).
Any mouse data packet that arrives after the position sampling, but before the reset is eliminated by the latter.
This was tested by sending a virtual mouse input through an arduino that moves the mouse left and right, back and forth, by the same amount very quickly. The crosshair would eventually drift to one side. This can be replicated without external hardware with ahk for anyone who's interested.
m_rawinput 1 measured up to 2.2ms of added input lag over m_rawinput 0 depending on how low your framerate is.
While during typical gameplay the delay is lower, this shows how the m_rawinput 1 method is not as good as it could be.
The latency varies with the fps and variable input lag is the most noticeable and annoying. During online gameplay the framerate undergoes noticeable variations and capping the framerate will not change the time the cpu takes to process the mouse input within single frames.
For the people saying that it's not perceivable: if it wasn't there would not have been any discussion about m_rawinput 1 feeling delayed in the first place.
Delay on constant movement is different from delay on a one time event, like a click, and is noticeable to some, specially if you're used to the more responsive method.
Regardless of that, the tests show that there is a measurable difference, therefore the built in raw input method is imperfect.
This is likely due to the fact that source engine was not originally built with raw input and it got patched in later.
Anyway, the solution already exists and is OPEN SOURCE code you can find here on github.
https://github.com/VolsandJezuz/Rinput-Library/releases
rinput works by hooking the calls for the windows cursor and replacing them with data from the raw input api (wm_input).
This method has the same latency as m_rawinput 0 but no packet loss, being the ideal way to handle the mouse.
It would be sad to waste that work and to have non optimal mouse handling in a competitive fps the caliber of csgo.
So please port the code to the game and add a m_rawinput 2 setting.
Thank you for your attention.
