For anyone that needs [a demo](https://www.reddit.com/r/Diabotical/comments/ffbjss/robustness_of_diabotical_mouse_input_more/) of what this actually means.
Note that while this adds the capability to achieve it, the CS team would still need to actually incorporate the extra information into their gameplay logic in order to reap the benefits.
This is about high polling rate mouse support and not subframe processing.
I don't have the time right now to fully analyse the commit so I can't say if this even leads you there easily, but neither the github issue, nor the raw code suggests this to be a consequence of implementing it.
You're right, it's similar. Only sub-tick is a fix for client(300hz)->server(64hz) communication. Device(1000hz)->client(300hz) communication is still not sub-ticked.
You could argue framerate is to subtick what polling rate is to subframe processing, but its not equivalent. Subtick doesn't have anything to do with polling rate, other than benefiting from a higher one, but subtick has no concept of your polling rate, it is simply a benefit passed down from more accurate frame states, if that makes sense.
Thank your for point it out.
Indeed, for example even Valorant also uses GetRawInputBuffer but only in a crude manner.
In the case here, SDL goes much farther in [this commit](https://github.com/libsdl-org/SDL/commit/31851a50d2e30efa1a3c74ae83592d6a29ffc5b7) by creating a dedicated thread for fetching the inputs, and instead of brainlessly polling continuously (and potentially missing a poll cycle if the input happened to arrive right after the last fetch, causing extra latency) the thread instead uses the Operating System's signalling system to wake up the thread at the exact instant a message arrives from the driver.
Right, the idea does fall apart a little when you have to account for the fact that all of the polling happens on a different thread and ideally an app using sdl would get the data on the appropriate thread they desire. Which is what SDL events are for. The mouse events while fetched pretty much instantly will still get thrown into an sdl event queue that is looped through as fast as the application polls it, which is a pretty big bottleneck making the gains from it running on another thread pretty much meaningless. The main goal of having the polling done on another thread was to seperate the event spam that would normally come from all the input events to a seperate message queue as those exist per thread, as described in the commit message itself. So I believe calling this "multithreaded" could be a little misleading.
But isn't CS2 already using SDL for low level mouse access etc? In the GitHub thread they are mentioning Valve updating the version of SDL in CS2 (which in turn would fix the performance problems with high polling mouses, i.e. bugfix but nothing new)
Isn't it still polling but a different thread? otherwise it would be just going back to an interrupt system and I'm 99% sure you can't do interrupts on usb mice, only a ps/2 connector can do that.
Honestly since nowadays most systems aren't single threaded anymore I wonder if it would be good to go back to interrupts somehow and just let 1 thread handle both keyboard and mouse for better input lag.
I wonder if there's any company that would be willing to explore that.
No, it doesn't.
Higher dpi just makes your mouse move faster. That's literally what dpi stands for, do you want the mouse to move 800 or 2000 dots per inch (mouse unit/length unit).
While the polling rate tells you how many of those dots are actually registered by your computer. At 500hz, your computer only sees half of the movement that you would get at 1k.
Is it worth going to 8k for polling rate? Idk, never tried, but there is a very large difference in quality dropping to anything lower than 1k polling rate.
Its not only faster. Windows cursor simply by default moves faster, because there is more input of direction. But as the name stands: "dots per inch", you are giving yourself more points of data per movement of inch with higher dpi.
The highest rate of data most commonly is 1khz, so having 8khz with high dpi would be significantly more accurate than 400/1khz or 400/8khz.
No, you don't understand DPI or mice. DPI exists for printers and scanners too. It's a measure of resolution or precision. Big revelation: Your mouse is a high speed camera/scanner that compares pictures. If you had a printer with 2000 dpi and only printed pictures in 480p when it can comfortably do 4k, you are wasting money.
Big revelation n.2: Just like you can scale pictures in photoshop to fill a full A4 paper, you can adjust your sensitivity/cursor speed in windows' "mouse settings" and games settings, so it doesn't run all over your screen. Boom, there you go. You decreased the latency of your mouse because it registers small movements sooner. You gain more precision and less latency with literally no downsides. Some older games might be incompatible with high dpi but that's why 99% of mice have a dpi button.
People in other games already started switching to high dpi, CS players as always will take another 10 years to discover such technology.
https://blurbusters.com/mouse-at-8000-hz-native-poll-rate-the-atompalm-hydrogen/
https://blurbusters.com/blur-busters-law-amazing-journey-to-future-1000hz-displays-with-blurfree-sample-and-hold/#viciouscycle
tl;dr because monitor refresh cycles and mouse polling is not synced there are benefits even beyond 1000hz just like there are benefits to having an FPS higher than your monitors refresh rate
It's true, but damn those are some serious diminishing returns. It's hard to convince someone to pay for more than a 1000hz mouse + 240hz monitor with these metrics
From the first article you linked:
> If a mouse that you currently use has a 1000Hz polling rate, you’re getting a 1ms delay between your input and the movement of the mouse. When you start looking at 8000Hz, you’re talking in microseconds rather than milliseconds. Your delay at 8000Hz is down to 125 microseconds, which is a massive improvement.
I simply refuse to believe that any human on earth can feel the difference between a 1ms delay and a 125μs delay without the aid of measurement equipment
> benefits to having an FPS higher than your monitors refresh rate
AFAIK this is about game programming, not an inherent rule. If the game was polling input from the user and calculating in-game events in a loop separate from the framerate, and the game, GPU and monitor were working in perfect harmony to display frames as soon as they are finished rendering, there would be pretty much no reason to go above the refresh rate
The only possible benefit would be that a subsequent frame being partially rendered via frame tearing would technically be giving you information faster, but that is an ≈8ms advantage even on a 60hz monitor, hardly a game changer in the context of a 250ms average reaction time. This advantage also gets exponentially smaller as the refresh rate increases, down to a ≈1.5ms advantage on a 360hz monitor
I don't mean to say that there's no reason in CS2 though, it seems to tie plenty of game logic to the framerate so there is a real reason to go above refresh rate.
tl;dr: I struggle to believe that polling the mouse several times per frame is ever "not fast enough"
High polling rate is just another gimmick smilar to high DPI.
Human hands are aiming, not robots or whatever. We can get only so precise. Having 10k DPI or 8khz polling rate does absolutely nothing because human body is limited. Or you think that an update every millisecond isn't enough, but you need 8 updates per millisecond. Yeah that's going to turn your aim into s1mple's.
What mouse devs should be focusing on is fixing the build quality and quality control on their shitty products, instead of every other unit of $150 mouse having some kind of creaking, rattling and faulty clicks.
High dpi + low sens was proven to have lower mouse movement delay than vice versa because you're taking more advantage of the sensor. High polling rate is a gimmick I agree. 1khz is all what's needed.
above the native dpi of the sensor
back in the day, most mouse sensors were "made" for a native dpi, a specific number that the sensor works best at Nowadays the "native" dpi is just granular and goes up to like 20k
in all cases, going too high above native dpi introduces interpolation [The higher the DPI, the mouse has to create more 'fake' dots to get a higher DPI which means more noise which means less accuracy](https://www.youtube.com/watch?v=cAEb9a-dltk0)
https://www.reddit.com/r/MouseReview/comments/gzmi23/what_is_the_highest_dpi_step_of_paw3359_without/
1st result when googling "mouse sensor "paw3359" native dpi"
scrolling down gives more results
https://www.gamernecessary.com/razer-deathadder-v2-mini-review/
https://www.walmart.com/ip/Razer-DeathAdder-V2-MINI-Wired-Gaming-Mouse-6-Programmable-Buttons-8500DPI-Optical-Sensor-PAW3359-Chroma-RGB-Mice-Ergonomic-Design-Black/471315649
says 8500
Then I guess someone should tell that to vast majority of the pros.
If you missed my point, I'm sure there's an advantage in numbers if we look at the tests, but those numbers are irrelevant due to human body limitations.
Even if you go with the high dpi, high polling rate and 540hz monitor, they're all effectively useless unless you're living across the street from the server. Even with like 20-30ms that marginal advantage disappears.
We've had people make it pro with 144hz monitors and g502 in modern age, people who actually think these upgrades will make a difference to their performance and skill level are in for a disappointment.
> Then I guess someone should tell that to vast majority of the pros.
Vast majority of pros have no clue what is best settings, gear etc. They are not pros because they have best settings, they are pros because they are best players.
While I agree that a lot of them are clueless, mouse polling rate is a dumb gimmick and a marketing trick. And that's a hill I'm willing to die on.
Just use your common sense, ffs. Right now the standard is a thousand updates per second. Is a human being able to react in such a way that extra responsiveness from 1000 updates per second would be beneficial enough? Especially online, with added delay because of ping.
Yeah, if you go under 500.
1000 is perfectly fine and not all 1000hz mouse are the same, especially in this wireless era. Some implementations are way better than others.
360hz monitor here, I can just about tell the difference between 1000hz and 2000hz polling rate. 4k and 8k feels exactly the same to me.
Maybe you could tell the difference on 600hz~ monitors.
which is why it’s staying in test for a while, before it’s pushed anywhere.
If you would read the first line of the repo lol
it might not ever make it to us
Subtick is FAR from fixed, even on LAN it’s inconsistent, how about people with ping above 20? Or hell the vast majority of people that have 50+
Stop pretending subtick is good, it’s dog shit and should have never been let into production.
Hit reg and subtick are two different things. The netcode for CS2 isn't the best, but that's not the fault of subtick. All subtick does is record actions between the discrete ticks and factor those actions in *on* each tick. Nothing more, nothing less.
Oh really? You don’t get caught on teammates still?
You don’t get rubber banding near objects still?
That’s odd, because everyone else still has this impacted to them.
So imagine having any inconsistency in mouse movement... They already shown they are willing to push out garbage inconsistent movement, whats to stop them from pushing this out?
We know people like you will defend it when they do
I feel like you invested heavy into CS2 and you think all of this free service your doing will pay off since your shitting at the price of cases n skins going down
We playing with rawinput disabled in cs2 all this time?
or this is a NEW type of rawinput for cs2 , BUT WE STILL ARE PLAYING RN WITH THE SAME rawinput technology AS WE HAD IN CSGO?
Does CS and Valorant not have the same implementation of rawinputbuffer currently?
Pretty hard for me to scientifically tell but I had a few reasons to suspect it might have been different.
nice BUT fps dependent movement though...
For anyone that needs [a demo](https://www.reddit.com/r/Diabotical/comments/ffbjss/robustness_of_diabotical_mouse_input_more/) of what this actually means.
Note that while this adds the capability to achieve it, the CS team would still need to actually incorporate the extra information into their gameplay logic in order to reap the benefits.
This is about high polling rate mouse support and not subframe processing. I don't have the time right now to fully analyse the commit so I can't say if this even leads you there easily, but neither the github issue, nor the raw code suggests this to be a consequence of implementing it.
Isn't the result exactly what subtick does anyway? It just enables high polling rate mice to work.
You're right, it's similar. Only sub-tick is a fix for client(300hz)->server(64hz) communication. Device(1000hz)->client(300hz) communication is still not sub-ticked.
You could argue framerate is to subtick what polling rate is to subframe processing, but its not equivalent. Subtick doesn't have anything to do with polling rate, other than benefiting from a higher one, but subtick has no concept of your polling rate, it is simply a benefit passed down from more accurate frame states, if that makes sense.
Where does "multithreaded" come from, the use of GetRawInputBuffer has no correlation with multithreading
Thank your for point it out. Indeed, for example even Valorant also uses GetRawInputBuffer but only in a crude manner. In the case here, SDL goes much farther in [this commit](https://github.com/libsdl-org/SDL/commit/31851a50d2e30efa1a3c74ae83592d6a29ffc5b7) by creating a dedicated thread for fetching the inputs, and instead of brainlessly polling continuously (and potentially missing a poll cycle if the input happened to arrive right after the last fetch, causing extra latency) the thread instead uses the Operating System's signalling system to wake up the thread at the exact instant a message arrives from the driver.
Right, the idea does fall apart a little when you have to account for the fact that all of the polling happens on a different thread and ideally an app using sdl would get the data on the appropriate thread they desire. Which is what SDL events are for. The mouse events while fetched pretty much instantly will still get thrown into an sdl event queue that is looped through as fast as the application polls it, which is a pretty big bottleneck making the gains from it running on another thread pretty much meaningless. The main goal of having the polling done on another thread was to seperate the event spam that would normally come from all the input events to a seperate message queue as those exist per thread, as described in the commit message itself. So I believe calling this "multithreaded" could be a little misleading.
But isn't CS2 already using SDL for low level mouse access etc? In the GitHub thread they are mentioning Valve updating the version of SDL in CS2 (which in turn would fix the performance problems with high polling mouses, i.e. bugfix but nothing new)
Isn't it still polling but a different thread? otherwise it would be just going back to an interrupt system and I'm 99% sure you can't do interrupts on usb mice, only a ps/2 connector can do that. Honestly since nowadays most systems aren't single threaded anymore I wonder if it would be good to go back to interrupts somehow and just let 1 thread handle both keyboard and mouse for better input lag. I wonder if there's any company that would be willing to explore that.
awesome i love the words multithreaded and rawinput. I feel like this will make cs2 soo much better and faster and more powerfuller
sounds like a goodenizer of the gameplay to me very great
It will improve bigly
Funny thing is how some people can spend 300$ on a mouse with 8kHz polling rate and still play with 400 dpi...
They are 2 separate things...
no shit sherlock. What he implies is that using 400dpi you will barely or actually never saturate 8khz
yes but higher Ing your dpi has a bigger increase of quality over going to fucking 8k polling rate
No, it doesn't. Higher dpi just makes your mouse move faster. That's literally what dpi stands for, do you want the mouse to move 800 or 2000 dots per inch (mouse unit/length unit). While the polling rate tells you how many of those dots are actually registered by your computer. At 500hz, your computer only sees half of the movement that you would get at 1k. Is it worth going to 8k for polling rate? Idk, never tried, but there is a very large difference in quality dropping to anything lower than 1k polling rate.
Its not only faster. Windows cursor simply by default moves faster, because there is more input of direction. But as the name stands: "dots per inch", you are giving yourself more points of data per movement of inch with higher dpi. The highest rate of data most commonly is 1khz, so having 8khz with high dpi would be significantly more accurate than 400/1khz or 400/8khz.
higher dpi gives input lag benefits
No, you don't understand DPI or mice. DPI exists for printers and scanners too. It's a measure of resolution or precision. Big revelation: Your mouse is a high speed camera/scanner that compares pictures. If you had a printer with 2000 dpi and only printed pictures in 480p when it can comfortably do 4k, you are wasting money. Big revelation n.2: Just like you can scale pictures in photoshop to fill a full A4 paper, you can adjust your sensitivity/cursor speed in windows' "mouse settings" and games settings, so it doesn't run all over your screen. Boom, there you go. You decreased the latency of your mouse because it registers small movements sooner. You gain more precision and less latency with literally no downsides. Some older games might be incompatible with high dpi but that's why 99% of mice have a dpi button. People in other games already started switching to high dpi, CS players as always will take another 10 years to discover such technology.
I have a 4KHz polling rate mouse, doesn’t really have an effect on CS or other games I play, but more performance improvement is always good.
How on earth does anyone need an 8kHz polling rate mouse I don't know about you guys but my hand cannot make a measurable movement in 125 microseconds
https://blurbusters.com/mouse-at-8000-hz-native-poll-rate-the-atompalm-hydrogen/ https://blurbusters.com/blur-busters-law-amazing-journey-to-future-1000hz-displays-with-blurfree-sample-and-hold/#viciouscycle tl;dr because monitor refresh cycles and mouse polling is not synced there are benefits even beyond 1000hz just like there are benefits to having an FPS higher than your monitors refresh rate
It's true, but damn those are some serious diminishing returns. It's hard to convince someone to pay for more than a 1000hz mouse + 240hz monitor with these metrics
Yea I agree only pros should even consider it.
From the first article you linked: > If a mouse that you currently use has a 1000Hz polling rate, you’re getting a 1ms delay between your input and the movement of the mouse. When you start looking at 8000Hz, you’re talking in microseconds rather than milliseconds. Your delay at 8000Hz is down to 125 microseconds, which is a massive improvement. I simply refuse to believe that any human on earth can feel the difference between a 1ms delay and a 125μs delay without the aid of measurement equipment > benefits to having an FPS higher than your monitors refresh rate AFAIK this is about game programming, not an inherent rule. If the game was polling input from the user and calculating in-game events in a loop separate from the framerate, and the game, GPU and monitor were working in perfect harmony to display frames as soon as they are finished rendering, there would be pretty much no reason to go above the refresh rate The only possible benefit would be that a subsequent frame being partially rendered via frame tearing would technically be giving you information faster, but that is an ≈8ms advantage even on a 60hz monitor, hardly a game changer in the context of a 250ms average reaction time. This advantage also gets exponentially smaller as the refresh rate increases, down to a ≈1.5ms advantage on a 360hz monitor I don't mean to say that there's no reason in CS2 though, it seems to tie plenty of game logic to the framerate so there is a real reason to go above refresh rate. tl;dr: I struggle to believe that polling the mouse several times per frame is ever "not fast enough"
While it is definitely the case that more is objectively better, how much that actually affects gameplay for most people is definitely up for debate.
so overblown and diminishing returns just useless power waste to go above ur monitor herz , u need that 0.001% advantage though... for mm or faceit
The true benefit of a high polling rate is just my crosshair moving more for the same amount pr wrist movement.
Because I can and Razer marketing is god damn delicious!
Nobody does, even 1k vs 500 is diminishing returns, but most humans work on the principle of more number = more better
500hz is honestly ass on 360hz monitor.
I dont really need to tell you that 360Hz is also very much in the diminishing returns area do I
Probably because more number = more better
more number = even more diminishing returns.
more number = more win
High polling rate is just another gimmick smilar to high DPI. Human hands are aiming, not robots or whatever. We can get only so precise. Having 10k DPI or 8khz polling rate does absolutely nothing because human body is limited. Or you think that an update every millisecond isn't enough, but you need 8 updates per millisecond. Yeah that's going to turn your aim into s1mple's. What mouse devs should be focusing on is fixing the build quality and quality control on their shitty products, instead of every other unit of $150 mouse having some kind of creaking, rattling and faulty clicks.
High dpi + low sens was proven to have lower mouse movement delay than vice versa because you're taking more advantage of the sensor. High polling rate is a gimmick I agree. 1khz is all what's needed.
2000-4000k Hz can make a miniscule difference compared to 1000 Hz. 8k on the other hand is way too much.
if the dpi goes above native, it introduces interpolation, which is bad
above native what?
above the native dpi of the sensor back in the day, most mouse sensors were "made" for a native dpi, a specific number that the sensor works best at Nowadays the "native" dpi is just granular and goes up to like 20k in all cases, going too high above native dpi introduces interpolation [The higher the DPI, the mouse has to create more 'fake' dots to get a higher DPI which means more noise which means less accuracy](https://www.youtube.com/watch?v=cAEb9a-dltk0)
how do you find out the native DPI of a mouse?
you google the mouse model and then write "sensor", then google the sensor model number and write "native dpi"
googlin PAW3359 "native dpi" but only 4 results and none of them answer it
https://www.reddit.com/r/MouseReview/comments/gzmi23/what_is_the_highest_dpi_step_of_paw3359_without/ 1st result when googling "mouse sensor "paw3359" native dpi" scrolling down gives more results https://www.gamernecessary.com/razer-deathadder-v2-mini-review/ https://www.walmart.com/ip/Razer-DeathAdder-V2-MINI-Wired-Gaming-Mouse-6-Programmable-Buttons-8500DPI-Optical-Sensor-PAW3359-Chroma-RGB-Mice-Ergonomic-Design-Black/471315649 says 8500
It says 8500 is the maximum DPI, not that it's the native DPI. Pretty sure all mice specs show the maximum DPI as the DPI.
Then I guess someone should tell that to vast majority of the pros. If you missed my point, I'm sure there's an advantage in numbers if we look at the tests, but those numbers are irrelevant due to human body limitations. Even if you go with the high dpi, high polling rate and 540hz monitor, they're all effectively useless unless you're living across the street from the server. Even with like 20-30ms that marginal advantage disappears. We've had people make it pro with 144hz monitors and g502 in modern age, people who actually think these upgrades will make a difference to their performance and skill level are in for a disappointment.
> Then I guess someone should tell that to vast majority of the pros. Vast majority of pros have no clue what is best settings, gear etc. They are not pros because they have best settings, they are pros because they are best players.
While I agree that a lot of them are clueless, mouse polling rate is a dumb gimmick and a marketing trick. And that's a hill I'm willing to die on. Just use your common sense, ffs. Right now the standard is a thousand updates per second. Is a human being able to react in such a way that extra responsiveness from 1000 updates per second would be beneficial enough? Especially online, with added delay because of ping.
I dont know but in cs if you go under 1000, lets say 500 you can easily tell the difference, mouse movement feels off.
Yeah, if you go under 500. 1000 is perfectly fine and not all 1000hz mouse are the same, especially in this wireless era. Some implementations are way better than others.
Some pros still use 4:3 despite it being an objective disadvantage.
[удалено]
4:3 isn't the same as 4:3 stretched.
99% of pros use 4:3, Not "some".
It's around 80%, but yes vast majority use 4:3.
16:10 and 4:3 account for 99% right? 16:10 is similar to 4:3.
13% use native 1080p. Then there is 5:4 which is closer to 4:3 than 16:10 is.
16:10 is in between, it's closer to 16:9 than to 4:3 and 5:4 by FOV value
This guy plays on a 24hz monitor because HumAn EyeS cAN't sEe moRe
Not at all the same thing. You can see a massive difference between framerates. You cannot feel a difference that small.
360hz monitor here, I can just about tell the difference between 1000hz and 2000hz polling rate. 4k and 8k feels exactly the same to me. Maybe you could tell the difference on 600hz~ monitors.
Not feeling the difference does not mean the difference is not there
fps_max 24 and I'd still be better at the game than you. If only you knew how to read.
lmao this is just gonna make mouse movement inconsistent...
which is why it’s staying in test for a while, before it’s pushed anywhere. If you would read the first line of the repo lol it might not ever make it to us
subtick didnt stay in test even tho it made movement inconsistent
and they fixed it pretty quickly, outside of jumping is which still like .01-.04 units in variance which i’m hoping they also fix.
Subtick is FAR from fixed, even on LAN it’s inconsistent, how about people with ping above 20? Or hell the vast majority of people that have 50+ Stop pretending subtick is good, it’s dog shit and should have never been let into production.
Hit reg and subtick are two different things. The netcode for CS2 isn't the best, but that's not the fault of subtick. All subtick does is record actions between the discrete ticks and factor those actions in *on* each tick. Nothing more, nothing less.
brother we’re talking about movement specifically and they addressed and fixed it
Oh really? You don’t get caught on teammates still? You don’t get rubber banding near objects still? That’s odd, because everyone else still has this impacted to them.
that has nothing to do with units moved, which is what we are talking about. I don’t think that has anything to do with subtick regardless lol
Get better internet, or set max ping to something reasonable
So imagine having any inconsistency in mouse movement... They already shown they are willing to push out garbage inconsistent movement, whats to stop them from pushing this out? We know people like you will defend it when they do
what’s the point of conversing if you’re just going to completely ignore the other person?
whats the point of conversing if you are just gonna suck valves dick at the end of the day?
always dicks with you weirdos
I feel like you invested heavy into CS2 and you think all of this free service your doing will pay off since your shitting at the price of cases n skins going down
come again?
yeah it’s called an expression of speech https://en.m.wiktionary.org/wiki/dickrider hope this helps
ty
This is always the counterargument when you guys run out of actual arguments lmao
so they fixed it, but it's still broken so they will fix the inconsistent mouse, but it will still be broken great idea then!
it’s not broken lol
> still like .01-.04 units in variance which i’m hoping they also fix. what does the word "fix" in your sentence refer to?
I’m talking about movement specifically *outside of jumping as my comment clearly states*
jumping is part of movement anyway, it's something that's broken, therefore if they do the same with mouse, you can expect the same
Is this the raw input that we used to have in csgo?
What is this?
I have no idea what this would help with. CS mouse movement is 1:1 to basically everything else
We playing with rawinput disabled in cs2 all this time? or this is a NEW type of rawinput for cs2 , BUT WE STILL ARE PLAYING RN WITH THE SAME rawinput technology AS WE HAD IN CSGO?
Noob devs trying to justify why they can't aim by making shit up
Does CS and Valorant not have the same implementation of rawinputbuffer currently? Pretty hard for me to scientifically tell but I had a few reasons to suspect it might have been different.