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

[lyrill]

Sensor framerate and sensor read frequency are two different things. Framerate would be how often the sensor takes and processes an image of the mousepad, sensor read frequency is how often the microcontroller reads position data from the sensor. You could have the sensor framerate at 20khz and only read the position registers at 1khz. There's not much point to reading the position registers faster than the USB polling rate you're using, provided you adjust timing so you read the sensor just before you expect to send it over USB. Sensor framerate on the other hand has more to do with how fast you're moving the mouse across the pad, it needs to be high enough that there's enough overlap to correlate the new frame to the old one. .

that's really a lot of bogged up technical loops lol. why can't sensor read simply be sensor frame??

The interface between the sensor and the microcontroller is much slower than the part of the sensor that captures and processes the image data to figure out how far you've moved. If you decrease the framerate, you also decrease the maximum speed you can physically move the mouse before it glitches out.

Think of the sensor framerate like the the crystal oscillator inside your watch, it oscillates at 32.768 khz as part of the internal operation of how it keeps time, even though you can only get the updated time once a second, and might only care to check the time once every few minutes.

haha thx that makes so much sense

[lyrill]

Sensor framerate and sensor read frequency are two different things. Framerate would be how often the sensor takes and processes an image of the mousepad, sensor read frequency is how often the microcontroller reads position data from the sensor. You could have the sensor framerate at 20khz and only read the position registers at 1khz. There's not much point to reading the position registers faster than the USB polling rate you're using, provided you adjust timing so you read the sensor just before you expect to send it over USB. Sensor framerate on the other hand has more to do with how fast you're moving the mouse across the pad, it needs to be high enough that there's enough overlap to correlate the new frame to the old one. .

that's really a lot of bogged up technical loops lol. why can't sensor read simply be sensor frame??

The interface between the sensor and the microcontroller is much slower than the part of the sensor that captures and processes the image data to figure out how far you've moved. If you decrease the framerate, you also decrease the maximum speed you can physically move the mouse before it glitches out.

Think of the sensor framerate like the the crystal oscillator inside your watch, it oscillates at 32.768 khz as part of the internal operation of how it keeps time, even though you can only get the updated time once a second, and might only care to check the time once every few minutes.

so just to clarify, your basically saying that this is part of and logically similar to the entire pc system including of course the whole mouse io hw+sw loop? meaning the cpu is at the heart and topmost in terms of hierarchy, like that oscillator? so it's naturally not a big deal that whatever the mouse has in any of its parts will never be as high since it's JUST not as complicated? (and this reminds me again, that a lot of mouse cost and price is bloated down to the shell and other parts.....not that cpu aren't overpriced.....)

[Sparky]

Sensor framerate and sensor read frequency are two different things. Framerate would be how often the sensor takes and processes an image of the mousepad, sensor read frequency is how often the microcontroller reads position data from the sensor. You could have the sensor framerate at 20khz and only read the position registers at 1khz. There's not much point to reading the position registers faster than the USB polling rate you're using, provided you adjust timing so you read the sensor just before you expect to send it over USB. Sensor framerate on the other hand has more to do with how fast you're moving the mouse across the pad, it needs to be high enough that there's enough overlap to correlate the new frame to the old one. .

that's really a lot of bogged up technical loops lol. why can't sensor read simply be sensor frame??

The interface between the sensor and the microcontroller is much slower than the part of the sensor that captures and processes the image data to figure out how far you've moved. If you decrease the framerate, you also decrease the maximum speed you can physically move the mouse before it glitches out.

Think of the sensor framerate like the the crystal oscillator inside your watch, it oscillates at 32.768 khz as part of the internal operation of how it keeps time, even though you can only get the updated time once a second, and might only care to check the time once every few minutes.

so just to clarify, your basically saying that this is part of and logically similar to the entire pc system including of course the whole mouse io hw+sw loop? meaning the cpu is at the heart and topmost in terms of hierarchy, like that oscillator? so it's naturally not a big deal that whatever the mouse has in any of its parts will never be as high since it's JUST not as complicated? (and this reminds me again, that a lot of mouse cost and price is bloated down to the shell and other parts.....not that cpu aren't overpriced.....)

I'm not sure what you're getting at.
There are two processors inside the mouse itself, one is inside the motion sensor, and processes image data to figure out how fast the mouse is moving(it takes a high framerate video input and turns it into x and y movement), the other, which I referred to as the microcontroller, communicates with the computer USB, gets input from the switches and mousewheel, communicates with the sensor over SPI, and does any other generic stuff like controlling a rgb LED.

The camera part of the sensor can only see a couple millimeters of the surface you have the mouse on, and you need two overlapping images in order to figure out what direction the mouse is moving, this determines the minimum framerate the sensor can run at. The PMW3360 for example can run that camera at 12,000fps. This is independent of the USB polling rate. As each of those image frames is 30~40 pixels square, the amount of data processed by the sensor to figure out where it is is easly a thousand times what your mouse is sending over USB.

The game itself might only need updated mouse position once per frame (as in your game framerate), but you want that updated position to be as fresh as possible, and with is as consistent a latency as possible, which is why there's a push for mice with higher polling rates. The part of the system that checks for mouse movement is running independently of the game code, so the easiest way to get the game fresher mouse data is to check the mouse position more often.

If you're familiar with why VRR monitors exist, this is a different approach to mitigating the same class of problem, just via brute force higher polling rate instead of synchronizing the mouse with the game engine. The brute force method is a lot easier here than in a monitor, because you only have a few bytes of data per sample, instead of the millions of bytes for each frame you send to a monitor.

[Chief Blur Buster]

Well, I'm under NDA so without revealing anything that's not already known.

I would actually encourage sharing your findings to fuel community discussion and the feedback loop. The NDA is really only in place to stop people from doing teardowns/reverse engineering and releveling any specific "trade secrets" (for the lack of a better word). If you want to share something but feel that you can't because of the NDA - just shoot us an email to verify.

As a reminder to everyone, now is the time to complain about game-specific quirks -- game-specific imprecise processing, so that the game developers can fix them before Viper hits the public.

Razer doesn't mind you to post more about clearly game-specific quirks ("...This game X behaves amazing with Viper, but on the other hand Game Y has this strange problem with Viper..."), so the developers can fix the issues before 8000Hz becomes popular. Because it's increasingly game engine imprecisions that now need to be improved in this refresh rate race to retina refresh rates.

Here's my beef: Cyberpunk 2077 imprecise mouse processing is holding back my Razer Viper. Some rounding error behaviors seem to be occurring in the game engine, compared to others.

Some report that 500 Hz poll rate feels better than 1000 Hz when it comes to Cyberpunk 2077. This is indicative of potential poor mouse mathematic hygene in the engine. See HOWTO: HOWTO: Please Future Proof your Game Engine for the coverage of this.

The HD Mouse API would greatly raise developer attention to this issue, because any user squealing about wanting support for HD Mouse API means the developers are forced to read best-practices documents related to HD Mouse API -- including all the math hygiene need to preserve sensortime:photontime as much as possible. It's amazing how dirty the mouse imprecision gets in some modern games because of bad math hygeine. Despite having ZERO mouse interpolation, ZERO mouse smoothing, ZERO mouse acceleration, the game engine is injecting its own unwanted effects from math flaws in the game engine.

Just by the MERE existence of HD Mouse API, probably will even improve the game engine's ability to process mouse from legacy mouse APIs. From the sheer learning experience alone.

[diakou]

Well, I'm under NDA so without revealing anything that's not already known.

I would actually encourage sharing your findings to fuel community discussion and the feedback loop. The NDA is really only in place to stop people from doing teardowns/reverse engineering and releveling any specific "trade secrets" (for the lack of a better word). If you want to share something but feel that you can't because of the NDA - just shoot us an email to verify.

As a reminder to everyone, now is the time to complain about game-specific quirks -- game-specific imprecise processing, so that the game developers can fix them before Viper hits the public.

Razer doesn't mind you to post more about clearly game-specific quirks ("...This game X behaves amazing with Viper, but on the other hand Game Y has this strange problem with Viper..."), so the developers can fix the issues before 8000Hz becomes popular. Because it's increasingly game engine imprecisions that now need to be improved in this refresh rate race to retina refresh rates.

Here's my beef: Cyberpunk 2077 imprecise mouse processing is holding back my Razer Viper. Some rounding error behaviors seem to be occurring in the game engine, compared to others.

Some report that 500 Hz poll rate feels better than 1000 Hz when it comes to Cyberpunk 2077. This is indicative of potential poor mouse mathematic hygene in the engine. See HOWTO: HOWTO: Please Future Proof your Game Engine for the coverage of this.

The HD Mouse API would greatly raise developer attention to this issue, because any user squealing about wanting support for HD Mouse API means the developers are forced to read best-practices documents related to HD Mouse API -- including all the math hygiene need to preserve sensortime:photontime as much as possible. It's amazing how dirty the mouse imprecision gets in some modern games because of bad math hygeine. Despite having ZERO mouse interpolation, ZERO mouse smoothing, ZERO mouse acceleration, the game engine is injecting its own unwanted effects from math flaws in the game engine.

Just by the MERE existence of HD Mouse API, probably will even improve the game engine's ability to process mouse from legacy mouse APIs. From the sheer learning experience alone.

I have used your discussion with the devs of this game(cloudpunk) and the post you made on here. To then pass forward as reference to some devs of other games that are currently in the process of attempting this (I'll update when I have new info, it's been about a month, but christmas + covid = not biggest priority right now) This Steam Release Notes

When you wrote this that one time;

Thus, I think by end of year, I'll be writing a Future Proof Your Game Engine article that touches on many weak links:

Did you mean the HD Mouse API post you made or a separate one at start of next year (since this year went by fast ;P) from a player perspective that has contacts - it is very, very easy to link and refer to the posts you make rather than attempting to 3rd-party convey information. A bonus effect is that for each dev and game that implements these things, it gets added onto a bigger and bigger list. Once that list has a few notable names - it quickly becomes a high priority attempt by other devs. I believe this to truly be the correct way to go about things for helping change the gaming landscape to keep up with the various changes that has happened.

I can't tell if it's confirmation bias or not - but ever since higher refresh rate monitors became more commodity and more powerful PCs have been available to the average user. I have seen more and more frequent posts about; "did X upgrade, things feel less smooth and I have problems" or "Got Y PC build for Christmas, but it feels more stuttery!" There's obviously so many reasons for this, but with each microsoft W10 update that introduces good new features, but breaks other things and/or bloats - the game devs need to utilize the new features or else players often are genuinely indeed getting more problems/worse performance than they had! (**cough** the last few NVIDIA drivers **cough**) A great example of this has always been the terrible flip model implementation by game developers over the years since Microsoft made a plea post about it when they first started making presentations about DX12 improvements in 2018. (Flip model is a DX11 thing as well - for users reading, even D3D9EX can do a sort of flip model for fullscreen and "lagless" borderless fullscreen)

I've had tremendous success conveying information and forcing change through multiple means, it often just requires barking up the right tree/department, with enough persistence without being annoying/disrespectful. So I vouch for this method and it really is a lot less futile than most people might think.

The easiest way to think about it is; How can I formulate the information I have for improving a game as a business argument? If you're able to convey that this will be a good thing for business reasons. Whether it's future proofing, being better than a competitor, keeping up with a competitor, will avoid bad reviews / show possible engagement disadvantages, good PR boost for being up to date / innovative, possible higher increased average game time per player / enjoyment -> indirectly leading to more commercial purchases (i.e free to play game)

Many, many approaches and methods. Just find the right fit.

[Chief Blur Buster]

I have used your discussion with the devs of this game(cloudpunk) and the post you made on here. To then pass forward as reference to some devs of other games that are currently in the process of attempting this (I'll update when I have new info, it's been about a month, but christmas + covid = not biggest priority right now) This Steam Release Notes

Hats off to you for being proactive!

Chief Blur Buster (moi) can only do so many things at once, so I appreciate when fans of Blur Busters can help spread the word to lift all boats for all gamers!

When you wrote this that one time;

Thus, I think by end of year, I'll be writing a Future Proof Your Game Engine article that touches on many weak links:

Did you mean the HD Mouse API post you made or a separate one at start of next year (since this year went by fast ;P)

No, it's a separate planned article, although I may have both articles to reference each other's articles (much like how my 1000Hz-Journey article and my Framerate-Amplification articles toot each other).

I can't tell if it's confirmation bias or not - but ever since higher refresh rate monitors became more commodity and more powerful PCs have been available to the average user. I have seen more and more frequent posts about; "did X upgrade, things feel less smooth and I have problems" or "Got Y PC build for Christmas, but it feels more stuttery!" There's obviously so many reasons for this, but with each microsoft W10 update that introduces good new features, but breaks other things and/or bloats - the game devs need to utilize the new features or else players often are genuinely indeed getting more problems/worse performance than they had! (**cough** the last few NVIDIA drivers **cough**) A great example of this has always been the terrible flip model implementation by game developers over the years since Microsoft made a plea post about it when they first started making presentations about DX12 improvements in 2018. (Flip model is a DX11 thing as well - for users reading, even D3D9EX can do a sort of flip model for fullscreen and "lagless" borderless fullscreen)

Yes, there's definitely a growing mainstream-ization of 120 Hz. It's not yet well known but with both Apple/Samsung going 120Hz across their full product suite within 5 years -- and parties such as DELL now considering adding 120 Hz to office monitors for ergonomic reasons.

But yes, monitors are getting complex. G-SYNC. FreeSync. Blur reduction. Low-lag modes. Etc. Bugs. We need to raise awareness.

...from a player perspective that has contacts - it is very, very easy to link and refer to the posts you make rather than attempting to 3rd-party convey information. A bonus effect is that for each dev and game that implements these things, it gets added onto a bigger and bigger list. Once that list has a few notable names - it quickly becomes a high priority attempt by other devs. I believe this to truly be the correct way to go about things for helping change the gaming landscape to keep up with the various changes that has happened.

I try to create main site Blur Busters articles, but these Forums are where I often incubate the material for my flagship articles.

Currently, I am having jorim help me re-section the main website, and most of the "valuable stuff" is the Area51 stuff -- www.blurbusters.com/area51 -- if you want a quick link to the Blur Busters magic sauce. A Developer-tagged section is coming once I've begun posting more developer-relevant content -- it might be a few months (mid 2021 ETA) since a lot of things are running on Valve Time (but trying to speed some things up!)

To help people look only at info on Blur Busters that only interest them (Because advanced users like you are getting bored of the mainstream cover page). I am slowly improving the sectioning Blur Busters, mainstream and advanced sections.
- /category/freesync (new monitors)
- /category/gsync (new monitors)
- /category/area51-display-research (my favorite articles)
- /category/testufo (writings about TestUFO)
etc.

New sections such as "Software Development" as well as things like "Gaming" will be added as enough articles appear on Blur Busters to warrant categorizing them. This time I'd like to accelerate advanced guest writing (articles more advanced than the coverpage stuff) by at least 10x in the coming 1-2 years. Many people who paid attention to Blur Busters early on, miss our regular advanced articles, but they're still there, in the hidden categories.

This will help you look up information that you can forward to software developers. But I have a chicken-and-egg problem: Content, content, content! Not mainstream writing. But advanced writing, like article submissions from esports athletes or coders, etc. So read on below:

I've had tremendous success conveying information and forcing change through multiple means, it often just requires barking up the right tree/department, with enough persistence without being annoying/disrespectful. So I vouch for this method and it really is a lot less futile than most people might think.

You're welcome to contact me at mark [at] blurbusters.com to help effect industry changes, especially since more help in one territory can help to up-prioritize certain Blur Busters initiatives.
____

[howiec]

The HD Mouse API would greatly raise developer attention to this issue, because any user squealing about wanting support for HD Mouse API means the developers are forced to read best-practices documents related to HD Mouse API -- including all the math hygiene need to preserve sensortime:photontime as much as possible. It's amazing how dirty the mouse imprecision gets in some modern games because of bad math hygeine. Despite having ZERO mouse interpolation, ZERO mouse smoothing, ZERO mouse acceleration, the game engine is injecting its own unwanted effects from math flaws in the game engine.

Just by the MERE existence of HD Mouse API, probably will even improve the game engine's ability to process mouse from legacy mouse APIs. From the sheer learning experience alone.

I think not only would this be extremely beneficial but would also be mandatory imo for a truly optimal gaming experience. I would imagine that some of the concepts would even overlap VR headset/peripheral input protocols too.

So far, 8kHz hasn't directly caused issues in any games I've played thus far.

However, 8kHz polling has definitely indirectly lead to stutter in games by affecting some other program features that I've used which monitor/track mouse position (e.g. Dual Monitor Tools).

One thing I noticed is that setting useplatformclock=True regardless of BIOS HPET setting leads to major stutter during faster mouse movements with 8kHz polling on my Z370 mb because it seems that Windows then uses the ACPI PMT (QPF = 3.57MHz) instead of TSC.

So overall, 8kHz itself has been a major boon for mouse responsiveness and smoothness but there's definitely a ton of room for improvement in the game engine/input design and other app compatibility.

[howiec]

I have used your discussion with the devs of this game(cloudpunk) and the post you made on here. To then pass forward as reference to some devs of other games that are currently in the process of attempting this (I'll update when I have new info, it's been about a month, but christmas + covid = not biggest priority right now) This Steam Release Notes

Keep it up man, we appreciate your efforts!

Definitely good to use those game dev contacts as that's not something many of us have.

[lyrill]

that's really a lot of bogged up technical loops lol. why can't sensor read simply be sensor frame??

The interface between the sensor and the microcontroller is much slower than the part of the sensor that captures and processes the image data to figure out how far you've moved. If you decrease the framerate, you also decrease the maximum speed you can physically move the mouse before it glitches out.

Think of the sensor framerate like the the crystal oscillator inside your watch, it oscillates at 32.768 khz as part of the internal operation of how it keeps time, even though you can only get the updated time once a second, and might only care to check the time once every few minutes.

so just to clarify, your basically saying that this is part of and logically similar to the entire pc system including of course the whole mouse io hw+sw loop? meaning the cpu is at the heart and topmost in terms of hierarchy, like that oscillator? so it's naturally not a big deal that whatever the mouse has in any of its parts will never be as high since it's JUST not as complicated? (and this reminds me again, that a lot of mouse cost and price is bloated down to the shell and other parts.....not that cpu aren't overpriced.....)

I'm not sure what you're getting at.
There are two processors inside the mouse itself, one is inside the motion sensor, and processes image data to figure out how fast the mouse is moving(it takes a high framerate video input and turns it into x and y movement), the other, which I referred to as the microcontroller, communicates with the computer USB, gets input from the switches and mousewheel, communicates with the sensor over SPI, and does any other generic stuff like controlling a rgb LED.

The camera part of the sensor can only see a couple millimeters of the surface you have the mouse on, and you need two overlapping images in order to figure out what direction the mouse is moving, this determines the minimum framerate the sensor can run at. The PMW3360 for example can run that camera at 12,000fps. This is independent of the USB polling rate. As each of those image frames is 30~40 pixels square, the amount of data processed by the sensor to figure out where it is is easly a thousand times what your mouse is sending over USB.

The game itself might only need updated mouse position once per frame (as in your game framerate), but you want that updated position to be as fresh as possible, and with is as consistent a latency as possible, which is why there's a push for mice with higher polling rates. The part of the system that checks for mouse movement is running independently of the game code, so the easiest way to get the game fresher mouse data is to check the mouse position more often.

If you're familiar with why VRR monitors exist, this is a different approach to mitigating the same class of problem, just via brute force higher polling rate instead of synchronizing the mouse with the game engine. The brute force method is a lot easier here than in a monitor, because you only have a few bytes of data per sample, instead of the millions of bytes for each frame you send to a monitor.

thanks for the detailed explanation again and sorry for late reply, and happy new year everyone! early morning here in Asia.

[deama]

Can you enable 8khz on linux? Does the razor software work on linux?
Also, what about the atom mouse, will that work on linux too?