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

[disq]

I use 800 on Apex and also wanted to try higher DPI, but as soon as one uses the loot inventory, mouse will fly through the monitor, makes it unplayable. Wish devs put more effort into adding options to control in-game menus sensitivity

[Chief Blur Buster]

I use 800 on Apex and also wanted to try higher DPI, but as soon as one uses the loot inventory, mouse will fly through the monitor, makes it unplayable. Wish devs put more effort into adding options to control in-game menus sensitivity

Yes. Separate sensitivity for in-game menus versus everything else.

Valorant doesn't require menus much so it's more manageable than Apex.

[sharknice]

Yeah a button on the mouse to switch DPI is very nice for that.

When I tested Valorant there was something wrong with the game at the very lowest sensitivity and it won't accurately pick up mouse movement. I can't remember the cutoff where it works accurately, but it still let's you get very low to take advantage of higher DPI. It runs like a dream when you get it tweaked properly. I tweaked my settings before I got to the target practice and got a perfect score the first try.

[Chief Blur Buster]

Yeah a button on the mouse to switch DPI is very nice for that.

When I tested Valorant there was something wrong with the game at the very lowest sensitivity and it won't accurately pick up mouse movement. I can't remember the cutoff where it works accurately, but it still let's you get very low to take advantage of higher DPI. It runs like a dream when you get it tweaked properly. I tweaked my settings before I got to the target practice and got a perfect score the first try.

I think I need to write a piece educating game developers ("Future Proof Your Game Engine" on how to properly add sensitivity settings. They need to be triple digit (1.000 down to 0.001) and always use double-precision mathematics (skip the float, skip the int, go straight to double). That's because gaming 400dpi at "1.000 Sensitivity" creates this situation

0400dpi at 1.0000 sensitivity
0800dpi at 0.5000 sensitivity
1600dpi at 0.2500 sensitivity
3200dpi at 0.1250 sensitivity
6400dpi at 0.0625 sensitivity

So future games need minimum 4 digits after the sensitivity, and allow keyboard typing-in the sensitivity, since sliders are too steppy/granular. Stop using 2 decimal digits for sensitivity settings.

Yes, it's overkill, but it's much easier to convert 400dpi to 6400dpi with zero fast flick turn feel. And when doing mathematics with other things (3D engine), floats can lose precision rather quickly over a long series of mathematics, so sometimes doubles are a good interim storage format between (int) then (double) then finally (float) since most GPUs are still generating 3D graphics at single precision to keep framerates high. Inside a monitor motherboard, it is like 10-bit color processing accepting the 8-bit GPU framebuffer to display onto an 8-bit monitor. It still helps reduce color banding (rounding errors from color processing). Likewise, you need higher-precision intermediate format sometimes to reduce rounding errors between source (mouse) and destination (3D render).

Some games are butter smooth on all monitors (50Hz through 360Hz) and all sync technologies (VSYNC ON, VSYNC OFF, VRR, G-SYNC, FreeSync) thanks to my help. For example, This Steam Release Notes credit me for helping refreshrate future-proof their game:

We would also like to thank community member Mark Rejhon of Blur Busters for his assistance and comprehensive testing of the stuttering issues.

So, I've already helped developers in improving variable refresh rate support, Unity Developers: Easy G-SYNC & FreeSync Support in only 3 lines of programming code! and schooling software developers on the The Amazing Human Visible Feats Of The Millisecond. Although I can sometimes be wrong, I've been proven right so frequently in this refresh rate race to retina refresh rates, that I've been cited in over 20 peer reviewed science/research papers, most recently by Samsung developing a new motion blur measurement method. My reputation now speaks for itself. Even my casual writings on these forums almost become textbook reading material when they regret not reading something I was right about 5 years ago.

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

• Any-VRR compatibility (See VRR developer HOWTO, don't stutter improperly on VRR)
• Any-Hz compatibility (See 1000Hz Journey, the holy grail to achieve lagless fullbrightness strobeless ULMB blurless sample-hold)
• Any-Hz mouse compatibility including 8000Hz mice including accurate between-frame button trigger mathematics.
• 55fps 55Hz CRU trick to debug non-60fps engine stutter if you're stuck on garden-variety DELL 60Hz office monitors
• 4-digit decimal sensitivity settings.
• Separate sensitivity settings for inventory menus (versus existing separate sensitivity settings for FPS / for scope). You can make them say "AUTO" to match Windows mouse pointer speed (check system metrics), while allowing you to configure in-game-engine sensitivity AND scope sensitivity.
• Use doubles for mouse mathematics, not integers or floats. Cast all int coordinates early as possible to doubles before mathing them! Allows mouse dpi to scale FAR better.
• Developer must understand the Vicious Cycle Effect to understand why futureproofing is critical (higher resolution amplifies Hz limitations; higher Hz amplifies resolution limitations, etc).
• Developer must understand Stutter-to-Blur continuum (like VRR demo, identical vision physics to guitar strings: slow strings vibrate, fast strings blur), and must whac-a-mole all single-pixel microstutter that can blend to 1-pixel motion blur, even 1000Hz mousejitter can do it too;
• Optimize asset loads as much as possible to be completely jitterless on normal SSDs. Small asset loads should not even have a 1 pixel microjitter (invisible at 60Hz LCD but visible during 240Hz ULMB 0.5ms MPRT)
• Don't stop there. Also optimize asset load stutters by testing your game engine in a RAMdisk or Optane memory. A game company should have at least 1 test system decked out for this testing purpose. Any asset streaming stutter becomes assumed a CPU/GPU inefficiency, not a disk assumption. Then asset streaming stutter becomes much easier to debug, and more futureproofed to future faster SSDs
• Never Make Assumptions about Human Visibility
• And MANY other Developer Best Practices for Refresh Rate Race to Retina Refresh Rates

These should be textbook programming best practices for game engines by well-capitalized gaming companies of the 2020s. What is invisible today can become visible tomorrow on better displays/GPUs/mice/etc.

<ShamelessBoast>
I'm not even dropping microphones anymore, they're now being golfed into holes-in-one. Let's golf that microphone 400 yards into a hole in one on the first try -- I've lost count of successfully holes-in-ones from my golfed microphones!
</ShamelessBoast>

UPDATE: I've crossposted a copy of this to HOWTO: Please Future Proof your Game Engine (Even if stuck on 60Hz Monitor) as an incubation area until I get around to writing the article

[lyrill]

Sorry for off-topic, but can a USB external sound card affect the variance for mouse/keyboard?

If it's in the same USB tree, possibly. Check your USB tree structure to make sure your internal hub isn't sharing continuous-bandwidth with an ultrahigh-pollrate device (4000Hz or 8000Hz). Play USB port roulette until they're on separate roots and you're usually golden. Purchase USB 3.0 PCI Express card as necessary (they're cheap, $30) to dedicate 4000Hz+ pollrate devices to them.

I purchased one and it actually made a difference to my 8000Hz mouse on a port-clogged system. At 1000Hz it is less important but at 8000Hz, USB traffic can crazily jitter things around on shared internal hubs. Many motherboards put 4 motherboard ports onto the same USB hub; that can be a problem when running multiple high pollrate / high bandwidth devices simultaneously.

You don't need high bandwidth, but a high bandwidth USB device can keep a hub busy for more than 0.125us, and another high pollrate device can contend a hub to degrade pollrate accuracy of 0.125us polls.

isn't it supposed to be independent as long as you see it on the motherboard inside being completely different module far seperated apart (like each one of them gathering dust from above easily cleaned up with finger+ room)

[lyrill]

I use 800 on Apex and also wanted to try higher DPI, but as soon as one uses the loot inventory, mouse will fly through the monitor, makes it unplayable. Wish devs put more effort into adding options to control in-game menus sensitivity

Yes. Separate sensitivity for in-game menus versus everything else.

Valorant doesn't require menus much so it's more manageable than Apex.

i'm in bfv and as soon as I switch to 1600dpi for longer range engagement my cursor moves like potato on everything else(including turning since I can't have time to find where that option is in game, and I believe it's none seperate anyways....or is it for MMG scope in ) so I just lowered my aiming sensitivity( is it generic aiming, i forgot). Then I get to just swipe more but more discrete, and then still keep the same everything else somehow (barely plays it once in 2 weeks but trying to find more time). This is on a final test batch (equiv to official batch, same as my Basilisk Ultimate #0013X, but this one does not have serial #) Vaxee Zygen, which I've confirmed with them to have zero smoothing across the board (well by that meaning 1600, and 3200, default steps lol, I'm also on a Tiger Esport Neon from their boss for free that they was to send out on the 8th but I don't use QQ much no more so missed the pm until couple days ago, was still on QCK HARD for lolz, finallys switched yesterday)

[lyrill]

Yeah a button on the mouse to switch DPI is very nice for that.

When I tested Valorant there was something wrong with the game at the very lowest sensitivity and it won't accurately pick up mouse movement. I can't remember the cutoff where it works accurately, but it still let's you get very low to take advantage of higher DPI. It runs like a dream when you get it tweaked properly. I tweaked my settings before I got to the target practice and got a perfect score the first try.

even the vpm and dam( or in more layman terms, ViperMini and DaV2 Mini) has one. and it's standard duo dpi on BAU, BAv2, DAv2, DAPro, Naga Pro. the viper to me doesn't exist lol. they were going lowest 184RMB that is 20 bucks+, and VPU is now going for 399RMB that is 50+ bucks without a dock. basically like official groupbuy but for "most popular line/shape), the vpm and dam have always also been cheap but never half off except once on the bam, and I got one for lolz, never even plugged in.

[Chief Blur Buster]

Game Engines need Instant API access to Full Mouse DPI Resolution

User-friendliness and developer-programming-friendliness are big problems in the DPI scaling race.

In the long term, true dpi-independent rawinput should be accessible. Basically game-engine-accessible DPI-adjustability. Or even a new Windows mouse API for accessing subpixel mouse pointer coordinates as doubles, for complete DPI-independence. It'd run at the maximum non-interpolated DPI. Deltas would be doubles, at the full DPI precision the mouse sensor is running at.

I have mentioned the theoretical subpixel mouse API to Razer, hopefully there's a future industry standard initiative (someday).

[lyrill]

Yeah a button on the mouse to switch DPI is very nice for that.

When I tested Valorant there was something wrong with the game at the very lowest sensitivity and it won't accurately pick up mouse movement. I can't remember the cutoff where it works accurately, but it still let's you get very low to take advantage of higher DPI. It runs like a dream when you get it tweaked properly. I tweaked my settings before I got to the target practice and got a perfect score the first try.

I think I need to write a piece educating game developers ("Future Proof Your Game Engine" on how to properly add sensitivity settings. They need to be triple digit (1.000 down to 0.001) and always use double-precision mathematics (skip the float, skip the int, go straight to double). That's because gaming 400dpi at "1.000 Sensitivity" creates this situation

0400dpi at 1.0000 sensitivity
0800dpi at 0.5000 sensitivity
1600dpi at 0.2500 sensitivity
3200dpi at 0.1250 sensitivity
6400dpi at 0.0625 sensitivity

So future games need minimum 4 digits after the sensitivity, and allow keyboard typing-in the sensitivity, since sliders are too steppy/granular. Stop using 2 decimal digits for sensitivity settings.

Yes, it's overkill, but it's much easier to convert 400dpi to 6400dpi with zero fast flick turn feel. And when doing mathematics with other things (3D engine), floats can lose precision rather quickly over a long series of mathematics, so sometimes doubles are a good interim storage format between (int) then (double) then finally (float) since most GPUs are still generating 3D graphics at single precision to keep framerates high. Inside a monitor motherboard, it is like 10-bit color processing accepting the 8-bit GPU framebuffer to display onto an 8-bit monitor. It still helps reduce color banding (rounding errors from color processing). Likewise, you need higher-precision intermediate format sometimes to reduce rounding errors between source (mouse) and destination (3D render).

Some games are butter smooth on all monitors (50Hz through 360Hz) and all sync technologies (VSYNC ON, VSYNC OFF, VRR, G-SYNC, FreeSync) thanks to my help. For example, This Steam Release Notes credit me for helping refreshrate future-proof their game:

We would also like to thank community member Mark Rejhon of Blur Busters for his assistance and comprehensive testing of the stuttering issues.

So, I've already helped developers in improving variable refresh rate support, Unity Developers: Easy G-SYNC & FreeSync Support in only 3 lines of programming code! and schooling software developers on the The Amazing Human Visible Feats Of The Millisecond. Although I can sometimes be wrong, I've been proven right so frequently in this refresh rate race to retina refresh rates, that I've been cited in over 20 peer reviewed science/research papers, most recently by Samsung developing a new motion blur measurement method. My reputation now speaks for itself. Even my casual writings on these forums almost become textbook reading material when they regret not reading something I was right about 5 years ago.

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

• Any-VRR compatibility (don't stutter improperly on VRR)
• Any-Hz compatibility (1000fps 1000Hz to achieve lagless fullbrightness strobeless ULMB blurless sample-hold)
• Any-Hz mouse compatibility including 8000Hz mice including accurate between-frame button trigger mathematics.
• 55fps 55Hz CRU trick to debug non-60fps engine stutter if you're stuck on garden-variety DELL 60Hz office monitors
• 4-digit decimal sensitivity settings.
• Separate sensitivity settings for inventory menus (versus existing separate sensitivity settings for FPS / for scope). You can make them say "AUTO" to match Windows mouse pointer speed (check system metrics), while allowing you to configure in-game-engine sensitivity AND scope sensitivity.
• Use doubles for mouse mathematics, not integers or floats. Cast all int coordinates early as possible to doubles before mathing them! Allows mouse dpi to scale FAR better.
• Developer must understand the Vicious Cycle Effect to understand why futureproofing is critical (higher resolution amplifies Hz limitations; higher Hz amplifies resolution limitations, etc).
• Developer must understand Stutter-to-Blur continuum (like VRR demo, identical vision physics to guitar strings: slow strings vibrate, fast strings blur), and must whac-a-mole all single-pixel microstutter that can blend to 1-pixel motion blur, even 1000Hz mousejitter can do it too;
• Optimize asset loads as much as possible to be completely jitterless on normal SSDs. Small asset loads should not even have a 1 pixel microjitter (invisible at 60Hz LCD but visible during 240Hz ULMB 0.5ms MPRT)
• Don't stop there. Also optimize asset load stutters by testing your game engine in a RAMdisk or Optane memory. A game company should have at least 1 test system decked out for this testing purpose. Any asset streaming stutter becomes assumed a CPU/GPU inefficiency, not a disk assumption. Then asset streaming stutter becomes much easier to debug, and more futureproofed to future faster SSDs
• Never Make Assumptions about Human Visibility
• And MANY other Developer Best Practices for Refresh Rate Race to Retina Refresh Rates

These should be textbook programming best practices for game engines by well-capitalized gaming companies of the 2020s. What is invisible today can become visible tomorrow on better displays/GPUs/mice/etc.

<ShamelessBoast>
I'm not even dropping microphones anymore, they're now being golfed into holes-in-one. Let's golf that microphone 400 yards into a hole in one on the first try -- I've lost count of successfully holes-in-ones from my golfed microphones!
</ShamelessBoast>

UPDATE: I've crossposted a copy of this to HOWTO: Please Future Proof your Game Engine (Even if stuck on 60Hz Monitor) as an incubation area until I get around to writing the article

You should (write something intentionally specific/concrete to, or I can just collade existing materials) persuade companies like Vaxee that insist on the old Benq by Zowie, I mean lol Zowie by Benq ways to at least up their top 3200dpi to 6400 dpi since that's higher than current (i mean 2019) touted top spec (no smoothing "no jitter") on truemovepro and similar.

Also yes it's unfortunate there are 400 dpi users "pros" even to this date, but I feel this is really only to "back promote" to them depending how big of an impact or "market sway" or "voice" they have, because we all know how there are a lot of 800 dpi users thanks to the uninitiated hivemind....but maybe a more progressive/aggressive thing to do is just to go by the 1-2 in game sense 2000-4000 dpi thing. Because to lower cost on high quality game pad, people should go back to size M, and yes that indeed means 300-400 by 250-400. Because if people like Razer Right themselves can adamantly claim that "anyone who cares about mouse sensor is living in 2009", well then care about the mouse pad then, it makes all the difference. I am still referencing Artisan Kai G2 Ultra Hyper (made around 2010-2011 ish, mimicking hard pad surface and mid layer, equivalent to Hard hardness gen 3) M(sized), and Ninja Ratmat lineup 001-004 with 005-007 in the making for some time (both largely unavailable to the general mass, oh and yeah, the Acari dropped some 30% ish in price too)

[lyrill]

Game Engines need Instant API access to Full Mouse DPI Resolution

User-friendliness and developer-programming-friendliness are big problems in the DPI scaling race.

In the long term, true dpi-independent rawinput should be accessible. Basically game-engine-accessible DPI-adjustability. Or even a new Windows mouse API for accessing subpixel mouse pointer coordinates as doubles, for complete DPI-independence. It'd run at the maximum non-interpolated DPI. Deltas would be doubles, at the full DPI precision the mouse sensor is running at.

I have mentioned the theoretical subpixel mouse API to Razer, hopefully there's a future industry standard initiative (someday).

this is cool indeed, like how everyone not insane basically uses/set 1khz (default on many mice anyways) and forget it.