Blur Busters Forums

Posted: **23 Dec 2020, 05:42**

Razer_TheFiend wrote: ↑
22 Dec 2020, 23:18
Yes, it's a faster microcontroller with USB high-speed. Sensor is not the same as standard Viper (3390), it's the same as the Viper Ultimate (3399).

I can't wait to try it, I wonder if the difference at 240hz is actually noticeable.
According to the Chief:

Chief Blur Buster wrote: ↑
29 Oct 2020, 18:23
120Hz display... I couldn't tell 1000Hz vs 8000Hz in nonstrobed operation. (Some others may, but I'm not THAT sensitive)
240Hz display... It's subtle. Differences are starting to reveal, especially if I turn on DyAc or ELMB, and use 3200dpi at windows desktop.
360Hz display... WOW, you definitely want 2000Hz+ pollrate even nonstrobed. Still can see 2000Hz vs 8000Hz pollrate difference with mousearrow circling test. I notice in 1-2 seconds of circling mouse arrow.

I fall into the 240hz strobing category, would it be possible that 1000hz was the microstutter bottleneck for motion blur reduction?
I'm still testing but I definitely notice a lot more microstutters at 500hz polling rate compared to 1000hz when using Dyac+ at 120hz and 144hz (If I record a video at 240/480fps).

I'm hoping that 8000hz brute refreshes can be the solution to forcing high dpi to make slow mouseturns more predictable on distant objects.

I wonder if Kephrii (the Overwatch player who released the Viper 8khz) has been using High Precision Mouse Input enabled with an 8000hz polling rate in Overwatch.
The developers of this game implemented a very interesting way to process polling rate in combination with the 62.5hz tick rate in order to make it possible to shoot between unrendered frames (or more importantly shoot during rendered frames inbetween ticks if your fps are above 63+).
Link for those of you interested: https://us.forums.blizzard.com/en/overw ... ion/422094

This approach should be an industry standard for self proclaimed competitive games.

Posted: **23 Dec 2020, 06:09**

Ogmilkman wrote: ↑
23 Dec 2020, 02:51
Given that 1000hz shows inconsistent movement on a 360hz monitor, could it be causing inconsistent engine-side movement in an FPS game at an fps >=360 regardless of the monitor refresh rate?

Theoretically, yes, and in practice, I believe so although my experience and evaluation is qualitative.

Whether it's a 3D pipeline or not, the sample rate issue/effect still exists.

However, the more complex the system/pipeline is, the more factors and interacting effects there are that can affect the end perceived result.

Most people only think of input delay/lag when they see polling rates, and do not really understand the concept of sampling rates.

Ultimately, you have this analog data (physical mouse position over time) that is being sampled and converted into a discrete digital value that is then also sampled and sent to the USB controller/CPU, which is then further sampled by the OS and/or game engine... This doesn't even include numerous other complexities and details like interrupt control schemes across the board.

So think of it this way, it doesn't matter if we have everything else at super high sample rates and under ideal conditions when the weakest link and bottleneck of said good data is a low USB sample rate.

Not all games and engines process mouse input the same. It depends on how well they optimize all the code for low latency, high input sampling rate, prioritized and consistent input processing per time period effectively decoupled from FPS, etc. So the issue can be quite complex.

Posted: **23 Dec 2020, 06:18**

axaro1 wrote: ↑
23 Dec 2020, 05:42
I fall into the 240hz strobing category, would it be possible that 1000hz was the microstutter bottleneck for motion blur reduction?

Well, I wouldn't say it's the only bottleneck but I would definitely gander that 8kHz will be a very noticeable improvement in overall smoothness in both non- and strobing conditions. Again, whether you strobe or not, the sample rate affects both scenarios as you're moving the mouse.

Posted: **23 Dec 2020, 06:22**

axaro1 wrote: ↑
23 Dec 2020, 05:42
The developers of this game implemented a very interesting way to process polling rate in combination with the 62.5hz tick rate in order to make it possible to shoot between unrendered frames (or more importantly shoot during rendered frames inbetween ticks if your fps are above 63+).
Link for those of you interested: https://us.forums.blizzard.com/en/overw ... ion/422094This approach should be an industry standard for self proclaimed competitive games.

Lol, funny that you posted this as I was typing my response above to Ogmilkman about game/engine coding as a major factor.

I find it extremely bizarre that basically at 2021 we are only starting to see devs take input processing and accuracy seriously when FPS games have been around for 25+ years...

Posted: **23 Dec 2020, 08:20**

howiec wrote: ↑
23 Dec 2020, 06:22
I find it extremely bizarre that basically at 2021 we are only starting to see devs take input processing and accuracy seriously when FPS games have been around for 25+ years...

Eh, it wasn't such a huge issue in the past. Try playing some old game on Windows 7, it will feel infinitely better than any new game on W10. Over time things got insanely bloated in both OS and games.

Posted: **23 Dec 2020, 08:58**

axaro1 wrote: ↑
23 Dec 2020, 05:42

Razer_TheFiend wrote: ↑
22 Dec 2020, 23:18
Yes, it's a faster microcontroller with USB high-speed. Sensor is not the same as standard Viper (3390), it's the same as the Viper Ultimate (3399).
I can't wait to try it, I wonder if the difference at 240hz is actually noticeable.
According to the Chief:
Chief Blur Buster wrote: ↑
29 Oct 2020, 18:23
120Hz display... I couldn't tell 1000Hz vs 8000Hz in nonstrobed operation. (Some others may, but I'm not THAT sensitive)
240Hz display... It's subtle. Differences are starting to reveal, especially if I turn on DyAc or ELMB, and use 3200dpi at windows desktop.
360Hz display... WOW, you definitely want 2000Hz+ pollrate even nonstrobed. Still can see 2000Hz vs 8000Hz pollrate difference with mousearrow circling test. I notice in 1-2 seconds of circling mouse arrow.
I fall into the 240hz strobing category, would it be possible that 1000hz was the microstutter bottleneck for motion blur reduction?
I'm still testing but I definitely notice a lot more microstutters at 500hz polling rate compared to 1000hz when using Dyac+ at 120hz and 144hz (If I record a video at 240/480fps).

I'm hoping that 8000hz brute refreshes can be the solution to forcing high dpi to make slow mouseturns more predictable on distant objects.

I wonder if Kephrii (the Overwatch player who released the Viper 8khz) has been using High Precision Mouse Input enabled with an 8000hz polling rate in Overwatch.
The developers of this game implemented a very interesting way to process polling rate in combination with the 62.5hz tick rate in order to make it possible to shoot between unrendered frames (or more importantly shoot during rendered frames inbetween ticks if your fps are above 63+).
Link for those of you interested: https://us.forums.blizzard.com/en/overw ... ion/422094

This approach should be an industry standard for self proclaimed competitive games.

pretty sure they just copied blurbuster

Posted: **23 Dec 2020, 09:00**

howiec wrote: ↑
23 Dec 2020, 06:09

Ogmilkman wrote: ↑
23 Dec 2020, 02:51
Given that 1000hz shows inconsistent movement on a 360hz monitor, could it be causing inconsistent engine-side movement in an FPS game at an fps >=360 regardless of the monitor refresh rate?
Theoretically, yes, and in practice, I believe so although my experience and evaluation is qualitative.

Whether it's a 3D pipeline or not, the sample rate issue/effect still exists.

However, the more complex the system/pipeline is, the more factors and interacting effects there are that can affect the end perceived result.

Most people only think of input delay/lag when they see polling rates, and do not really understand the concept of sampling rates.

Ultimately, you have this analog data (physical mouse position over time) that is being sampled and converted into a discrete digital value that is then also sampled and sent to the USB controller/CPU, which is then further sampled by the OS and/or game engine... This doesn't even include numerous other complexities and details like interrupt control schemes across the board.

So think of it this way, it doesn't matter if we have everything else at super high sample rates and under ideal conditions when the weakest link and bottleneck of said good data is a low USB sample rate.

Not all games and engines process mouse input the same. It depends on how well they optimize all the code for low latency, high input sampling rate, prioritized and consistent input processing per time period effectively decoupled from FPS, etc. So the issue can be quite complex.

you forgot sampled by the server (tick)

Posted: **23 Dec 2020, 09:01**

howiec wrote: ↑
23 Dec 2020, 06:22

axaro1 wrote: ↑
23 Dec 2020, 05:42
The developers of this game implemented a very interesting way to process polling rate in combination with the 62.5hz tick rate in order to make it possible to shoot between unrendered frames (or more importantly shoot during rendered frames inbetween ticks if your fps are above 63+).
Link for those of you interested: https://us.forums.blizzard.com/en/overw ... ion/422094This approach should be an industry standard for self proclaimed competitive games.
Lol, funny that you posted this as I was typing my response above to Ogmilkman about game/engine coding as a major factor.

I find it extremely bizarre that basically at 2021 we are only starting to see devs take input processing and accuracy seriously when FPS games have been around for 25+ years...

didn't click the link but that feature was out like a year ago or something

Posted: **23 Dec 2020, 12:58**

Brainlet wrote: ↑
23 Dec 2020, 08:20

howiec wrote: ↑
23 Dec 2020, 06:22
I find it extremely bizarre that basically at 2021 we are only starting to see devs take input processing and accuracy seriously when FPS games have been around for 25+ years...
Eh, it wasn't such a huge issue in the past. Try playing some old game on Windows 7, it will feel infinitely better than any new game on W10. Over time things got insanely bloated in both OS and games.

In Windows 7 days, we didn't have refresh rates high enough to show poll rate limitations of mice.

360 Hz on Windows 7 will still show limitations of 1000 Hz mice too.

New Blur Busters Rule Of Thumb: Mouse Poll Rates Should Be At Least 5-6x Higher Than Refresh Rate

Even 2000 Hz is a massive improvement for 360 Hz, you don't need to use 8000 Hz.

Posted: **23 Dec 2020, 18:30**

lyrill wrote: ↑
23 Dec 2020, 09:00
you forgot sampled by the server (tick)

That doesn't affect your input/ouput chain on the client side (with client-side prediction, hit-detection, etc.), but it does affect hit registration, actual location, etc. in the server game state/time.

On a side note, most games have lousy netcode these days, especially in BRs. I'm guessing Valorant is one of the exceptions but it's easier when player count and world complexity is so much lower.

Blur Busters Forums

I have the new Razer 8000 Hz prototype gaming mouse on my desk.

Re: I have the new Razer 8000 Hz prototype gaming mouse on my desk.

Re: I have the new Razer 8000 Hz prototype gaming mouse on my desk.

Re: I have the new Razer 8000 Hz prototype gaming mouse on my desk.

Re: I have the new Razer 8000 Hz prototype gaming mouse on my desk.

Re: I have the new Razer 8000 Hz prototype gaming mouse on my desk.

Re: I have the new Razer 8000 Hz prototype gaming mouse on my desk.

Re: I have the new Razer 8000 Hz prototype gaming mouse on my desk.

Re: I have the new Razer 8000 Hz prototype gaming mouse on my desk.

Re: I have the new Razer 8000 Hz prototype gaming mouse on my desk.

Re: I have the new Razer 8000 Hz prototype gaming mouse on my desk.