Page 6 of 72

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

Posted: 03 Oct 2020, 07:33
by Xzwer
Can't believe no one has asked, when do you plan to release this mouse? :D

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

Posted: 03 Oct 2020, 14:44
by howiec
Xzwer wrote:
03 Oct 2020, 07:33
Can't believe no one has asked, when do you plan to release this mouse? :D
It's been asked. Razer said the prototype works well but there are other things like game compatibility they they want to work out with the devs first prior to release. So no date yet but hopefully soon.

World's first 8kHz mouse (without manual driver hacks) is a good marketing point...

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

Posted: 03 Oct 2020, 16:07
by NDUS
howiec wrote:
03 Oct 2020, 14:44
World's first 8kHz mouse (without manual driver hacks) is a good marketing point...
The Atompalm Hydrogen will almost certainly be releasing prior to this mouse

It also has various other goodies besides the 8khz polling rate, like set & latch debounce, super low weight, etc. Time will tell whether Atompalm or Razer's implementation of 8khz is better, though.

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

Posted: 03 Oct 2020, 16:27
by howiec
NDUS wrote:
03 Oct 2020, 16:07
howiec wrote:
03 Oct 2020, 14:44
World's first 8kHz mouse (without manual driver hacks) is a good marketing point...
The Atompalm Hydrogen will almost certainly be releasing prior to this mouse

It also has various other goodies besides the 8khz polling rate, like set & latch debounce, super low weight, etc. Time will tell whether Atompalm or Razer's implementation of 8khz is better, though.
I know and that's why I'm subtly trying to get Razer to up their game.

Optical switches theoretically should always be faster than any mechanical with debounce but latency reduction there while welcome is not a huge concern for me.

Razer will most certainly have an advantage overall due to optimizing more items in the mouse system (marketed as Motion Sync) unless Atom Palm does something similar.

Unfortunately, I know I prefer small ergo mice for my grip style so obviously shape is another huge factor in which mouse is "better" for us individually.

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

Posted: 04 Oct 2020, 05:27
by rasmas
Do we know what sensor will it have? (to know about input lag/ maybe is 100% new).


Also , as we have a Razer representative(? :D ): can we suggest mice designs somewhere?
If you don't mind here: I love one design a lot of mice of different brands have used (i know who is the original designer), and is the best mice i've ever used. I would love to have it with good quality senson-components and on some brand that keep that design for years (is a pain to find the new brands).

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

Posted: 04 Oct 2020, 10:42
by Razer_TheFiend
Chief Blur Buster wrote:
02 Oct 2020, 10:42
I'd rate this camera-Hz configurability sync as a priority 2 in a scale of 1 through of 5 (unimportant through highest). Useful, but focus on priorities first. If it's easy to go to 24KHz, do that, and call it a day. 24KHz is conveniently divisible by 500, 1000, 2000, 4000 and 8000.

But the poll Hz achievement is WAY more important. And system timing jitter (0.125us imprecisions) will be a bigger jitter noise margin.

All part of the textbook Vicious Cycle Effect that is the huge raison d'etre of the refresh rate race bringing visible human benefits.
Locked 24k fps isn't quite possible on the sensor. 20k is the max persistent framerate we can do while still maintaining sensor performance.

And yes, the order of our priorities is the same. Poll Hz achievement first, beat frequency achievement second - if we want to keep to it, then 16000fps is where we'll need to lock it.
MaxTendency wrote:
02 Oct 2020, 11:32
Thanks for the explanation. This leads me to another question. Will higher DPI be beneficial to high polling rate?

From your example if I move the mouse 4000 count in a sec this leads to half the polls being null. However if I move the same distance physically in a sec on x2 the DPI that would double the counts and it would saturate the 0.125ms polling interval preventing half the polls being null.

And while we're on the topic of DPI , will this mouse have smoothing at higher dpi? If the answer is unfortunately yes, then can you leak at which DPI step the additional smoothing will be induced?
If your eDPI is the same (i.e. 800dpi x 1.0 ingame vs 1600dpi x 0.5 ingame) I don't believe it will make any difference for you in-game. Goes without saying you should not be using an ingame sens higher than 1.0.

Our focus+ sensor has no smoothing across the dpi range - all the way to 20k.
howiec wrote:
03 Oct 2020, 14:44
It's been asked. Razer said the prototype works well but there are other things like game compatibility they they want to work out with the devs first prior to release. So no date yet but hopefully soon.
I hope so too, but we're cautious of releasing "too soon" because for the 95th percentile user, it's very easy to blame the mouse for causing issues with games/apps "when it works fine with my XYZ mouse".

As I said before, the hardware is 99% ready, it's just working out the kinks that we're focused on now. Some of them might be solvable by driver workarounds, some simply require game/app dev intervention. This was partly the intent of making this announcement now, so that we can show game devs/microsoft that this is something that people want and is worth their effort.

For the record : we did the same for phones with 120Hz screens in 2017, most mobile games didn't support 120Hz refresh rates until we reached out to them and got them to support it.
rasmas wrote:
04 Oct 2020, 05:27
Do we know what sensor will it have? (to know about input lag/ maybe is 100% new).
It's a cut-and-dry answer :it will be our Focus+ sensor - optimizing performance minutiae at higher polling rates was one of the our key considerations when we started working with Pixart on the sensor in 2016.

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

Posted: 04 Oct 2020, 11:34
by kurtextrem
Maybe this is an idea: I remember you guys from Razer made a website for requesting a left-handed mouse. Why not do the same for this 8k Hz mouse? Offer it to the people who want it, let them buy & test it. As example, Withings, a smartwatch/fitness company did the same: they let 1000 people buy the first "ScanWatch" batch and then waited a month to get feedback. An "early buyers" group certainly knows why they want it and might be able to give good feedback. Win-win for us (users) and you (the company).

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

Posted: 05 Oct 2020, 07:44
by Alpha
Chief Blur Buster wrote:
02 Oct 2020, 10:27
howiec wrote:
02 Oct 2020, 10:21
This is one of those things where someone has to take the lead in driving change which can have direct and indirect costs but at the same time can also be rewarding from capitalizing on it from a marketing standpoint.
And for computers / GPUs / refreshrates / etc to catch up.

Fewer 8000Hz-incompatible computers needed to still be around, and enough 8000Hz-compatible computers to be around (in terms of fast enough to handle all those polls without creating problems making it worse than 1000Hz).

BTW, the mainstream sites have published their articles, but I want to take a different approach to testing this mouse and publishing something properly Blur Busters flavored, like all my "Area 51" worthy articles.
Chief, what is the ideal dpi for 360hz displays @ 1000hz polling? Can't wait to see your article with 8000hz but where are we at with 1000hz and DPI now?

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

Posted: 05 Oct 2020, 08:16
by axaro1
Razer_TheFiend wrote:
04 Oct 2020, 10:42

As I said before, the hardware is 99% ready, it's just working out the kinks that we're focused on now. Some of them might be solvable by driver workarounds, some simply require game/app dev intervention. This was partly the intent of making this announcement now, so that we can show game devs/microsoft that this is something that people want and is worth their effort.

For the record : we did the same for phones with 120Hz screens in 2017, most mobile games didn't support 120Hz refresh rates until we reached out to them and got them to support it.
I can definitely feel the limits of 1000hz polling rate, at 144hz it was much less noticeable but now that I've got a 280hz monitor I can see the microstutters with a naked eye, more so if I take a 960fps recording of the screen while moving my mouse at a consistent speed.

When are you guys planning to release this model? I'd love to try it.

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

Posted: 05 Oct 2020, 08:22
by Chief Blur Buster
Razer_TheFiend wrote:
04 Oct 2020, 10:42
If your eDPI is the same (i.e. 800dpi x 1.0 ingame vs 1600dpi x 0.5 ingame) I don't believe it will make any difference for you in-game. Goes without saying you should not be using an ingame sens higher than 1.0.
1600dpi at 0.5 feels better than 800dpi at 1.0.

This is because games is able to render in a subpixel way.

0.5 “antialases itself” over movements. Especially during super slow mouse turns. Regardless of whether you turn AA on, The 1.0 movements look more non-antialiased, steppy-steppy by 1 pixel jumps is visible at 1080p-and-below resolutions, as I move a sniper lens around. If I use sub-1 sensitivity settings, movements are subpixel-smoooooth!

Even in faster TestUFO-speed turns (960pps to 1920pps), big differences below 1 such as 1.0 vs 0.25 is even visible for strobed operation (ULMB, ELMB, DyAc, PureXP). The turns feels slightly less jittery while you eyetrack scenery that scrolls past during a mouseturn.

My prediction is future 1000Hz monitors (that makes it unnecessary to turn on strobe-based blur reduction, since brute Hz is the blur reduction method instead), may also exhibit this “below 1.0 is beneficial” effect.

Test Cases
1. Slower drifting movements (like sniper): 1.0sens @ 400dpi versus 0.25sens @ 1600dpi creates visible differences on all my monitors at all refresh rates.
2. Medium TestUFO-speed movements (Eye trackable turns): Need approx MPRT 1ms or less to notice

To be able to tell, remember to use bigger dramatic differences to punch geometrically up the diminishing curve of returns (much like 1000Hz vs 8000Hz).
Instead of [email protected] vs [email protected], please compare:
- [email protected] vs [email protected]

This behaves like 4x antialasing, instead of 2X antialiasing, in a motion-context. I'd call it "lagless mouse motion antialasing" (if someone had to coin a marketing term). This allows you to avoid smoothing/interpolation algorithms, and simply use "brute DPI + brute poll" as a motion antialiaser feature for high unreprocessed dpi.

The brute DPI helps slow turns better, and the brute poll helps fast turns better. Having both brutes is one-size-fits-all for all mouse movements, from super ultraslow (sniper lens slow-tracking a few pixels per second) to super fast (fast 180 flick turns).

You know when you're using a sniper in your favourite FPS shooter game, from say, 1000 meters away from a tiny target near the horizon, and the target is moving slowly horizontally? And you have to slow-track your sniper lens sideways at a few pixels per second? Slow aim-tracking manoevers. Here, even 1-pixel steppy-steppy-steppy is noticeable, so sub-1.0 sensitivity settings here REALLY helps make it pixelless, with subpixel mouse motion antialiasing! It's terrible if you dare to use sensitivity 2.0 or higher, but numbers below 1.0 can begin to become a noticeable improvement during these situations.

Test this with a very good mousepad that the mouse tracks very well on, so you don't even have any subpixel tracking-related jitter (video noise in the mouse sensor, too glass-smooth / too-dark surface, etc).
Razer_TheFiend wrote:
04 Oct 2020, 10:42
Our focus+ sensor has no smoothing across the dpi range - all the way to 20k.
That’s fantastic!

In theory, I’d even prefer 3200dpi at 0.25 or 6400dpi at 0.125 to max the benefits of antialaised slow mouseturns, like when zoomed-sniper-lens.

More games need finer sensitive settings like ability to adjust with two or three decimal digits, since we need a 0.125 sensitivity setting (at 3200dpi) to exactly match 1.000 (at 400dpi) for same-speed fast flick turns. Old games had very granular sensitivity settings, which don't play well with high-dpi tuning.

If you send a Best Practices document to game developers (say "Game Development Best Practices for Razer 8000Hz Mouse"), please cover these topics as part of game-developer training:
(A) Sensitivity behavior for mouse turn operation (why subpixel is good)
(B) Sensitivity behavior for sniper scope operation (why subpixel is good)
(C) Sensitivity behavior for mouse arrow for menu-selecting manoevers (subpixel isn't important; mousefeel similar to Windows more important -- we don't want it to behave like a rocket so lower sensitivity to simulate 400dpi and 800dpi is useful)

In fact, I am going to mention this in Blur Busters Mouse Guide #2 (supplement to the very old Mouse Guide).
Razer_TheFiend wrote:
04 Oct 2020, 10:42
I hope so too, but we're cautious of releasing "too soon" because for the 95th percentile user, it's very easy to blame the mouse for causing issues with games/apps "when it works fine with my XYZ mouse".
I agree. There are some “weird effects” on some of my multiple computers, but not others. An old copy of Microsoft Excel had a lagging effect during window dragging on a slower GPU — it was probably inefficiently trying to redraw at 8000fps.

Fortunately, I’m imagine the usual mouse drivers will have Hz-switching in profiles so I can blacklist specific apps.
Razer_TheFiend wrote:
04 Oct 2020, 10:42
Our focus+ sensor has no smoothing across the dpi range - all the way to 20k.
20,000dpi?

Mouse nirvana occurs when combining high Hz + high DPI.

I wish there was a higher DPI setting than the yellow setting on my 8000 Hz prototype which seems to be behaving like 1600dpi (in Windows, moving 1600 pixels for one inch of mousepad move). I am looking forward to testing 3200dpi and higher in the motion-antialiased sniper "slow-aim-tracking" situation; I know 3200dpi is crap on many mice (interpolated and/or smoothed) but if your 8000Hz sensor can do 6400dpi natively, then that might even become my default setting because it's like 16x "motion AA" for slow-aim-tracking scenarios.

Thinking of possible test cases.

One might want to add "sniper slow-aim-tracking" test cases for your DPI settings. And make sure 6400dpi 0.125sens feels _exactly_ the same as 800dpi 1.0sens for fast flick turns -- zero lag differentials preferably (or even less lag for 6400dpi 0.125sens).

Create an application that logs data for:
(A) 8000Hz [email protected] versus 8000Hz [email protected], latency difference for turn start/stop
(B) 8000Hz [email protected] versus 8000Hz [email protected], latency difference for turn start/stop
(C) 1000Hz [email protected] (on same sensor) versus 8000Hz [email protected]

Do many fast mouse movements (spin the cursor, setc) and log the X,Y coordinates and compare standard deviation.
- Run the program twice, once at 8000Hz at higher DPI, again at 1000Hz at lower DPI
- For the 8000Hz dataset, drop all numbers except the nearest 1ms polls, for more symmetric 1:1 comparision with the 1000Hz dataset
- For the 1000Hz dataset, multiply the 1000Hz positions by 8.
- Calculate delta of all the adjacent mouse positions (separately for X and for Y).
- Compute the standard deviation (volatility of mouse movements).
- Ideally the standard deviation should be roughly the same.

See if it is least least approximately the same standard deviation; this shows smoothing wasn't used during pollrate/dpi increases, that no smoothing sheninigians was done by your mouse sensor vendor (if not in-house). If standard deviation fell, then it means there is some unexplained smoothing going on.

To convince people that they should now be using 3200dpi or 6400dpi instead of 400dpi or 800dpi, requires showing proof of benefits. In this case, different sensitivity settings may be necessary for mouse cursor in-game versus sniper sensitivity versus mouseturn sensitivity; because ultrahigh DPI is beneficial for motion antialiasing behaviours. The Blur Busters recommendation has always been to use the highest DPI you can get that doesn't have compromises.

Everyone uses different sensitivity settings but the sniper-slow-aim motion antialiasing (of higher dpi) can be favourably used whenever it has no penalty (no added artificial smoothing, no added latency, no added interpolation, no accuracy loss) -- and that fast flick turns feel exactly the same as before, same speed.

The biggest problem is mouse cursors becoming too fast at high DPI, but that can be made an independent sensitivity setting than scope operation / turn operation, as a game-programming best-practice.

With so many esports players hell bent at staying at 800dpi, it is a bit of a user education to explain the "lagless mouse motion antialiasing" benefits of 3200dpi and 6400dpi for ultraslow mouse movements. The problem is 3200dpi and 6400dpi historically has been sketchy in past mouse sensors, and it is going to take a mountain of user education to remove this myth. The lack of smoothing/interpolation (whether intentional or unintentional) at ultra-high DPI is a boon for precision physical-to-screen at all motionspeeds, including ultraslow tracking.

The sudden punch up the diminishing curve of returns (1000Hz->8000Hz, and 800dpi->6400dpi) is a hugely beneficial catchall for all possible mouse movement speeds (major poll-increase benefitting faster movements, major dpi/sens rebalance benefitting slower movements), of the variety of game behaviours, variety of sync technologies, and variety of refresh rates -- all of which can interact to amplify visibility of mouse poll Hz limitations.

The descendants myths of "Humans can't tell 30fps vs 60fps" that Blur Busters loves to cover!