Hi guys,

since i got much time now (thanks corona 🤢 hope everyone is fine) i start testing m_rawinput 1 vs 0 again.

Hint:  u need to have stable fps on m_rawinput 0

First the backgrounds, it was testet that m_rawinput 1 does not generate any input lag and works the way it should.

But only normal mouse movements were tested with a script.

I claim that m_rawinput 1 doesn`t capture small mouse movements correctly.

Try:   1. On a pistol server m_rawinput 1 vs 0 u notice headtracking is much easier with 0, u dont overshoot when enemies strafing (AD AD AD)

          2. Spray on a wall its much easier with m_rawinput 0

Why?!?! Small mouse movements are not perceived so u move ur mouse more and overshoot (test 1) or fuck up your spray cause u pull the mouse slowly down but the mouse movement dont get detected. (test 2)

This is where you come in. I do not want to make any claims, I want to prove that something is wrong. The only question is how can I do that? Any help is welcome

 

 

Edited March 21, 20206 yr by Quackerjack

You can prove mouse input is not working correctly very easily without any human "feels". That's the purpose of scripts - If a game doesn't drop counts when sent at any speed, then it's working, and if the sensitivity (distance turned) remains stable no matter the hz the counts are sent, then there is no packet loss of counts (negative accel) and no designed acceleration either (positive accel). You measure all this over multiple turns to be even more precise than to even 1 pixel.

I don't play CS, but I would have thought if the raw input implementation worked anything other than flawlessly, then DPI Wizard would have noticed.

maybe, but what if m_rawinput 1 add m_filter 1. How u test that?

 

found this thread:

and this post:

soonpls

 

FaZe Clan Fan

1 point · 3 years ago

 

technology evolved since 1.6 days nowadays, most mouses have filter inside their software. there's lots of things that are different in csgo, like using m_rawinput 1 and m_mousespeed 0 - gives you a similar feeling to m_filter 0, but it's still not the same.

What i've experienced is having the DPI as close as possible to the resolution, so for 1920x1080 - 1800 dpi, for 800x600 - 800dpi, etc. and adjusting your sens to have the same 360 sens you have now, will get you a snappy gameplay and on-point aiming, decreases the smoothness. try that, maybe it'll help you as well.

tl;dr m_filter is irelevant these days. closest way to reproduce it is m_rawinput 1; m_mousespeed 0 (dont do that use m_mousespeed 1)

 

And this solved every Problem for me mouse is 1:1 now

 

Edited March 21, 20206 yr by Quackerjack

I don't really understand the issue you say you were having though on a factual level. What problem was solved?

You say that the game was not responding to small mouse movements?

Well that's easy to test - send one count at various frequencies. Does it always move? Then there's no problem. Does it sometimes no respond? Then you have an issue.

Again, this isn't a complex science or black magic  - there's nothing mysterious about it.

What you don't do is move your mouse around with your hand and try and do stuff by "feel" if you want accurate facts. By far the most common cause of error with things like this is simply between the chair and the keyboard.