Blur Busters Forums

sk1p wrote: ↑

21 Apr 2021, 04:26

I'm done with my tests on 8k Viper. Any of polling rate above 1000hz leads to inconsistent aim in CS GO, but at the first look it works fine, so to my opinion technology it's too raw and 1000hz still the best(just work stable).

Kamen Rider Blade wrote: ↑

21 Apr 2021, 02:50

Since 8 kHz is the official "Upper Limit" of USB Polling based on the smallest possible Micro-Frame Packet Time Interval allowed via USB standard.

Kamen Rider Blade wrote: ↑

21 Apr 2021, 02:50

But given what I analyzed, we have 28 possible Whole Integer Refresh Rates that align around the integer based Micro-Frame Packets. That's 24 more than is already specified by USB IF (Implementors Forum) and Spec.

Chief Blur Buster wrote: ↑

21 Apr 2021, 06:18

sk1p wrote: ↑

21 Apr 2021, 04:26

I'm done with my tests on 8k Viper. Any of polling rate above 1000hz leads to inconsistent aim in CS GO, but at the first look it works fine, so to my opinion technology it's too raw and 1000hz still the best(just work stable).

CS:GO doesn't work well as Valorant. Try retesting your tests with newer engines such as Valorant.

IMHO, CS:GO needs a modification by Valve to work more reliably with >1000Hz and high-DPI operation.

Chief Blur Buster wrote: ↑

21 Apr 2021, 06:18

Kamen Rider Blade wrote: ↑

21 Apr 2021, 02:50

Since 8 kHz is the official "Upper Limit" of USB Polling based on the smallest possible Micro-Frame Packet Time Interval allowed via USB standard.

Check out my proposal: High Definition Mouse Extensions API

This optionally decouples USB poll from sensor rate, while relaying the whole sensor rate to PC. 20KHz accurately microsecond-timestamped coordinates transmitted in batches at lower poll is possible.

Kamen Rider Blade wrote: ↑

21 Apr 2021, 02:50

But given what I analyzed, we have 28 possible Whole Integer Refresh Rates that align around the integer based Micro-Frame Packets. That's 24 more than is already specified by USB IF (Implementors Forum) and Spec.

I think introducing a HD Mouse API is a MUCH easier battle, and latency consistency would be better with microsecond sensor-side timestamps. At the 125us timescales, latency consistency becomes a more pressured factor than reducing average latency even further. (Also latency consistency = less likely to microstutter).

It's a lower lying apple with bigger benefits to end users & easier to deploy than a USB IF modification.

It does not preclude USB IF modification too, as HD Mouse API does not assume the connection is USB-based, or even synchronous.

Razer also expressed potential interest in this type of front.

Thoughts? Since you sound technically knowledgeable from the sound of your posts, I'd love your comments about refining the HD Mouse API proposal. You can reply here or in that thread.

masneb wrote: ↑

20 Apr 2021, 00:21

ChillyRide1712 wrote: ↑

19 Apr 2021, 19:20

Valorant, CS:GO show fps drops when fast moving mouse, but if u cap ur fps to lowest ur saw its fine and playable. No problems with fps drops in Overwatch where my 5700xt on 90+% usage at 400 fps. Basically CPU struggle to register fast movements or it is supposed to work like that, dont know, but I fixed sttuters and improve fps by closing services and apps in background.

I have a 5900x as well and it doesn't come close to maxing out a core running at 8k polling. The current problems with 8k have nothing to do with CPU utilization unless you're running a really low end PC. A 5900x has 12 cores, CSGO definitely doesn't peg all of those cores, therefore you'll never run into a CPU bottleneck specifically in that game with that processor.

The problem with 8k has something to do with USB being unable to handle the amount of polling it's doing, games not being able to deal with that much input data, the mouse still being in it's infancy, or a combination of the above. I basically run the mouse at 1k now to avoid such situations. Sometimes games will seemingly handle it well, then freak out on occasion. I have another one where it actually causes reduced input, the mouse input slows down like I'm decreasing the DPI when I go to 8k. Have another one that causes microstuttering and hitching. Another in which it seems like it skips inputs erratically from the mouse, like it's dropping some inputs and that relationship isn't linear, so it'll lead to erratic movement.

I still also have a problem where the mouse cursor on occasion will start freaking out either when not even touching the mouse or when I'm actually using it. It will erratically 'vibrate' between two different positions like it loses tracking. It's very easy to see when it's doing this if I'm watching a youtube video and it's sitting in the window. When the controls disappear, any movement from the mouse causes them to come back. Normally I would think that's related to the surface it's on, but it doesn't matter what I use. That started happening when I upgraded from the launch firmware. Both of the newer ones still have this issue.

Kamen Rider Blade wrote: ↑

21 Apr 2021, 15:27

Chief Blur Buster wrote: ↑

21 Apr 2021, 06:18

Kamen Rider Blade wrote: ↑

21 Apr 2021, 02:50

Since 8 kHz is the official "Upper Limit" of USB Polling based on the smallest possible Micro-Frame Packet Time Interval allowed via USB standard.

Check out my proposal: High Definition Mouse Extensions API

This optionally decouples USB poll from sensor rate, while relaying the whole sensor rate to PC. 20KHz accurately microsecond-timestamped coordinates transmitted in batches at lower poll is possible.

Kamen Rider Blade wrote: ↑

21 Apr 2021, 02:50

But given what I analyzed, we have 28 possible Whole Integer Refresh Rates that align around the integer based Micro-Frame Packets. That's 24 more than is already specified by USB IF (Implementors Forum) and Spec.

I think introducing a HD Mouse API is a MUCH easier battle, and latency consistency would be better with microsecond sensor-side timestamps. At the 125us timescales, latency consistency becomes a more pressured factor than reducing average latency even further. (Also latency consistency = less likely to microstutter).

It's a lower lying apple with bigger benefits to end users & easier to deploy than a USB IF modification.

It does not preclude USB IF modification too, as HD Mouse API does not assume the connection is USB-based, or even synchronous.

Razer also expressed potential interest in this type of front.

Thoughts? Since you sound technically knowledgeable from the sound of your posts, I'd love your comments about refining the HD Mouse API proposal. You can reply here or in that thread.

I love your TimeStamp concept for HD Mouse API, but the issue with it is Game Developer support and getting USB IF to add it to the spec as a future feature. And then, if USB-IF only makes it "Optional", the chances of adoption go down.

Also, will Windows & Linux adopt it?

The fact that you want to make it "Optional" is the real weakness, if it's "Optional", we see how support on "optional" features have been in many game titles. Does anybody remember PhysX? nVIDIA Hair Works?

Implementation wise, I think it's fine as is since you're just presenting mouse data with a Time Stamp so that the end developer can process it in temporal FIFO order. You kept it simple, which is optimum, but making it optional is the real weak spot IMO.

And getting USB-IF to try to force this new paradigm of mouse tracking won't be easy if you want to see any significant adoption rate. I bet they'll think the current paradigm is fine and won't understand our needs for it since they don't see latency as that significant of an issue.

We're the ones pushing for fixing "Latency" issues. Regular USB folks just really care about compatibility & bandwidth.

My idea is wonky in it's own way since it adds 24 more Refresh Rate options for a total of 28 options with 3 slots for User Customizeable Polling Rates based on Integer amounts of Micro-Frame Packets. But that's the rub. I'm just creating more Polling Rate options out of the existing ones for a total of 32 slots for "Default Polling Rate" choices.

My idea doesn't bring any changes to the Game Developer side since most of the chances will be at a USB Driver level.

Yeah, there might be some bugs that arise from it since I have a wide range of polling rates, but I'm going down a different rabbit hole for USB and for different reasons.

Power Savings on certain USB devices is one of those reasons, along with different Higher Polling Rate options than the stock 4 choices we have now.

I guess we both have our different causes to fight for in the face of USB Standards =D.

masneb wrote: ↑

22 Apr 2021, 00:00

Has anyone tried the mouse yet with a thunderbolt port? Would be very interested once again if these issues are present with it. I don't have TB and you can't add TB to Ryzens. You can use an adapter to use a USB mouse on TB.

lyrill wrote: ↑

22 Apr 2021, 00:23

but it isn't about latency