CS:GO and m_rawinput 1

[katte]

Hey DPI Wizard.

 

I see you have a lot of knowledge on mouse input in games. There has been a large discussion of CS:GO and it's m_rawinput. Some people feel a huge difference using rinput.exe instead of rawinput 1. No one has never investigated if it has acceleration with its own rawinput option. Can you look into this?

[DPI Wizard]

Ok, so I've tested it quickly now, and here are the results...

First of all, none of the input methods have any acceleration. But some of them have packet loss.

This means that a packet from the mouse instructing the game to move X amounts of counts are lost somewhere between the mouse and the game engine.

 

m_rawinput 1: 0% packetloss, as accurate as it can possibly get.

m_rawinput 0 and rinput: some packet packet loss, must test more to see how much

 

I can dig deeper and get accurate numbers if this is interesting

[katte]

Thanks for the great answer. So m_rawinput 1 it is!

 

E: if I may ask, what methods you used to test this?

Edited September 6, 2015 by katte

[katte]

And please dig deeper. Which method has the least input lag? Many of the pros are in believe that rinput.exe is the way to go. This could be huge.

Edited September 6, 2015 by katte

[DPI Wizard]

I will do a detailed analysis, and try to make a video.

[DPI Wizard]

Do people use this launcher, or is there another preferred way of running rinput?

[katte]

I've been using Rinput 1.31 that can be downloaded from various places. Never used that though.

[Attiaz]

DPI Wizard 

I have just created this account to talk about this.

i have been testing and changing my sensitivity for 4 - 5 days 

 

its not only about m_rawinput 0/1

there is also m_mousespeed 0 / 1 which even if you turn mouse acceleration off from csgo its sill set to "1"

 

for me m_mousespeed 1 have some acceleration on fast movement so i set to 0

 

m_rawinput 1 vs rawinput 0 both with  m_mousespeed 0

 

m_raw 1 feel more faster and obvious sensitivity change  

 

so for now im playing with  m_ rawinput 0 and  m_mousespeed 0

 

could you please test these ?

m_ rawinput 1  m_mousespeed 1

m_ rawinput 1  m_mousespeed 0

 

m_ rawinput 0  m_mousespeed 1

m_ rawinput 0  m_mousespeed 0

 

i use win 8.1 no mouse fix 500hz 

 

Thank you 

[puelo]

Hi,

 

which version did you use for your above measurements? There are two different versions: sequential/non-sequential, which can be found here:

http://blog.digitalise.net/category/programming-scripting/cplusplus/win32/

 

This is how i usually start the RInput.exe (inside a .bat file)

@echo off
start steam://rungameid/730
timeout /T 10 /NOBREAK >nul
start "" "C:\Program Files (x86)\RInput\RInput.exe" csgo.exe
timeout /T 1 /NOBREAK >nulexit:

Hope this helps. Really interested for the result you get.

Edited September 6, 2015 by puelo

[nullz]

Just to inform a little about m_mousespeed.

 

First of all, i doesnt do ANYTHING AT ALL, unless you have "-useforcedmparms" in the launch options. 

 

I'ts been a while since i read about it, but im pretty sure that the m_mousespeed command was added to combine the 2 launch options -noforcemaccel and -noforcemspd. (Neither of theese two commands work without "-useforcedmparms"

So if you want to use m_mousespeed you should not have any of thoose two in your launch options.

Further more all m_mousespeed does, is enabling/disabling windows acceleration. They added the command, to be able to have accelration in windows and not in CS and vice versa.

If you want to try this out, make sure that you only have -useforcedmparms in your launch options. Join a local game, minimize the game, open control panel -> mouse -> pointer options and see if "Enhance pointer precition" is checked. If it is, go back to the game, and change m_mousespeed to 0, else to m_mousespeed 1. You can now minimize the game again, and see that EPS is opposite of before.

So to sum up, m_mousespeed just forces "Enhance Pointer Precision" on or off.

Edited September 6, 2015 by nullz

[DPI Wizard]

 

Hi,

 

which version did you use for your above measurements? There are two different versions: sequential/non-sequential, which can be found here:

http://blog.digitalise.net/category/programming-scripting/cplusplus/win32/

 

This is how i usually start the RInput.exe (inside a .bat file)

@echo off
start steam://rungameid/730
timeout /T 10 /NOBREAK >nul
start "" "C:\Program Files (x86)\RInput\RInput.exe" csgo.exe
timeout /T 1 /NOBREAK >nulexit:

Hope this helps. Really interested for the result you get.

 

I'll test both of them.

[qsxcv]

hello, just wanted to let you know that i've noticed the same phenomenon here:

http://www.overclock.net/t/1545382/csgo-m-rawinput-0-drops-samples

 

no one really knows why, i guess it's due to the potential for a packet/motion event to arrive between the calls to getcursorpos and setcursorpos which is what source games use when m_rawinput is 0.

 

how did you measure/estimate those numbers?

[DPI Wizard]

hello, just wanted to let you know that i've noticed the same phenomenon here:

http://www.overclock.net/t/1545382/csgo-m-rawinput-0-drops-samples

 

no one really knows why, i guess it's due to the potential for a packet/motion event to arrive between the calls to getcursorpos and setcursorpos which is what source games use when m_rawinput is 0.

 

how did you measure/estimate those numbers?

 

I set a sensitivity that eqals exactly 1000, 10000 and 100000 counts/360, and use scripting to emulate mouse movement using different report sizes and rates.

 

BTW, the numbers in my first post here are off, it's not as much as 5%. I'm doing some more extensive testing now.

[DPI Wizard]

Are there any reports regarding rinput and Windows 10? I get it injected successfully, just wondering if it works correctly.

[katte]

I'm using Windows 10 and I guess it's working as intended

[thejoy]

Hello, rinput.exe user here.

 

Would there be any reason why rinput.exe would behave differently on w7 and w10 ? If you have a machine running on w7 I'm interested to know.

 

Also, is packet loss also implies input lag or it's two different things ?

 

PS: If m_rawinput and rinput.exe are not removing any accel, what are they here for ? (assuming you're using 6/11 on windows, epp off). Is any difference I feel between the 3 are only placebo ? (dig deeper, shaun-T style)

Edited September 7, 2015 by thejoy

[DPI Wizard]

Hello, rinput.exe user here.

 

Would there be any reason why rinput.exe would behave differently on w7 and w10 ? If you have a machine running on w7 I'm interested to know.

 

Also, is packet loss also implies input lag or it's two different things ?

I don't think there's any reason why it should behave differently, but I can maybe do some tests on w7 to verify later.

 

Packet loss isn't input lag, but it might be perceived as it if it is enough of it.

Packet loss = Packets sent but never processed by the game.

Input lag = Packets sent and processed later than expected.

 

Unfortunately I don't have the necessary equipment to test for input lag, but based on test I've seen on other sites it's only a matter of a few milliseconds, so it shouldn't be noticable.

[thejoy]

Ok thanks. Can't wait to see your results.

[Xbye]

I would like to add on to this discussion what I've gathered as I use SourceGL (which uses rInput). I'm very sensitivity to input lag, so this is what I've gathered:

 

m_rawinput in source-engine games does it's job... however it seems to do it very slowly that it's a noticeable difference. I think some CS:GO pro players are even playing with m_rawinput 0 in their configs.

 

Doing some tests between 0 and 1 for m_rawinput in Left4Dead 2 on a local server... I found a nearby tree, and aimed at the base. I proceeded to "A+D spam" while attempting to to keep my crosshair at the base of the tree. With 1, I had typical trouble and found myself aiming off the tree a quite a bit but able to keep it centered for the most part. I then used 0 and found I was able to keep my cross centered at the base of the tree far longer and more consistently. I then went on to test m_rawinput 0 for 2 weeks and came to a conclusion.

 

Using 0 instead of 1 resulted in significantly noticeable (least to me, but I'm sensitive to this shit) less input lag. However, using 0 you are at the mercy of your frame-rate and I would constantly have my game get weird... "lock ups" for about 1-2 frames whenever I was turning. Overall, that just wasn't worth it for me to use 0 over 1. I'd rather have more input lag with consistency, than less input lag with inconsistency.

 

SourceGL(and rInput) is something the players with 0 m_rawinput are using in cs:go I believe. It's become a big thing I suppose. I've been using it for a while and haven't ran into any particular problems but due to how rInput works I can't do a quick side-by-side comparison of m_rawinput 1 vs SourceGL vs m_rawinput 0. It does feel like there is less input lag, but I could be wrong. I need to do a test by toggling the features which isn't something I'm interested in.

[thejoy]

 

 

Doing some tests between 0 and 1 for m_rawinput in Left4Dead 2 on a local server... I found a nearby tree, and aimed at the base. I proceeded to "A+D spam" while attempting to to keep my crosshair at the base of the tree. With 1, I had typical trouble and found myself aiming off the tree a quite a bit but able to keep it centered for the most part. I then used 0 and found I was able to keep my cross centered at the base of the tree far longer and more consistently. I then went on to test m_rawinput 0 for 2 weeks and came to a conclusion.

 

Could you run the same test in CS:GO ? (the thing with the tree). Maybe the L4D rawinput is flawed, who knows. I myself feel a difference of responsiveness between the two, I have no idea if it's input lag or not, I'm not even sure if It's a placebo or not.

 

 

 

However, using 0 you are at the mercy of your frame-rate and I would constantly have my game get weird...

 

Are you atthe mercy of your frame-rate even with rinput.exe ?

[Xbye]

Could you run the same test in CS:GO ? (the thing with the tree). Maybe the L4D rawinput is flawed, who knows. I myself feel a difference of responsiveness between the two, I have no idea if it's input lag or not, I'm not even sure if It's a placebo or not.

 

 

Are you atthe mercy of your frame-rate even with rinput.exe ?

No, I don't believe you are at the mercy of your FPS using rInput... it seems to work just like raw input. However, I don't specialize in this area. I will say though that FPS flucuates quite a bit in L4D2 even with beastly computers (300 fps - 150 fps) because of poor optimizations in some areas, which might lead me to believe the game is engine bound rather than cpu/gpu bound. With FPS fluctuations like that, I think it's safe to say that rInput (at least SourceGL) isn't at the mercy of your FPS.

 

I don't own CS:GO, so I can't really test it. I also don't really have any plans to buy it since it looks like a boring game to me. If someone gifted me it I'd probably test it. People are always wanting me to play it.

Edited September 9, 2015 by ball2hi

[DPI Wizard]

I'm doing a lot of tests on CS:GO now, will do tests with and without vsync, with different count sizes and timings. About 1000 tests in total to get some reliable data, so it will take some time.

[StillBlaze]

I'm doing a lot of tests on CS:GO now, will do tests with and without vsync, with different count sizes and timings. About 1000 tests in total to get some reliable data, so it will take some time.

You are a credit to gaming, keep up the good work! Will be here when your finished to gain a proper understanding.

[Vols and Jezuz]

I'm guessing RInput loss will be closer to an order of magnitude lower than your original figures after you have all the data. As you've already stated that your initial 5% figure is off, I think you should consider editing the original post because a lot of people will just read the first few posts and take it as the word of god.

 

If a small amount of packet loss is demonstrated with RInput, I still would see it as a tradeoff with m_rawinput 1, with the former having small packet loss while the latter has added input lag. It's been pretty convincingly demonstrated that m_rawinput 1 has a flat ~1.5ms input lag penalty, which may sound insignificant, but when you've fine tuned your aim to rely on extremely fast and precise flicks, twitches, and grandiose swipes, it can be perceptibly detrimental. I'm currently working on trying to implement some kind of A/B blind test into sourceGL so that we can at least get some practical-use user statistics for detecting/preferring one implementation of raw input over the other.

 

Off the top of my head, some things I would like to see tested with your methodology (which I presume you will thoroughly expound upon when you release your collected data): effects 1) across varying hardware/OS/software setups (this may not be reasonable for you to do if you only have one primary system), 2) of mat_queue_mode 0 v. 1 v. 2, 3) of having CS:GO process priority set to AboveNormal and High, as well as Steam processes set to BelowNormal, 4) of having Steam overlay disabled/enabled, and 5) of having things like minimal and optimized Windows services running and no fan controller software (static fan speeds).

 

'ppreciate your efforts in providing us we some experimental data and I look forward to seeing your results!

[DPI Wizard]

I'm guessing RInput loss will be closer to an order of magnitude lower than your original figures after you have all the data. As you've already stated that your initial 5% figure is off, I think you should consider editing the original post because a lot of people will just read the first few posts and take it as the word of god.

Good point, edited my first post.

 

 

If a small amount of packet loss is demonstrated with RInput, I still would see it as a tradeoff with m_rawinput 1, with the former having small packet loss while the latter has added input lag. It's been pretty convincingly demonstrated that m_rawinput 1 has a flat ~1.5ms input lag penalty, which may sound insignificant, but when you've fine tuned your aim to rely on extremely fast and precise flicks, twitches, and grandiose swipes, it can be perceptibly detrimental. I'm currently working on trying to implement some kind of A/B blind test into sourceGL so that we can at least get some practical-use user statistics for detecting/preferring one implementation of raw input over the other.

 

As stated earlier I won't be able to test for input lag at this point, but as it has been tested before, I can go by those numbers and calculate if the tradeoff is worth it.

 

 

2) of mat_queue_mode 0 v. 1 v. 2, 3) of having CS:GO process priority set to AboveNormal and High, as well as Steam processes set to BelowNormal, 4) of having Steam overlay disabled/enabled, and 5) of having things like minimal and optimized Windows services running and no fan controller software (static fan speeds).

I won't be able to test it all this time around, but when I'm done I'll do some more tweaking maybe.