qsxcv

there's no point really to doing anything in-game. about my flatness concern again: the nice thing about the figure 8 pattern is that the drift from that effect is zero, to first order (i.e. assuming that the difference in the mouse's plane of motion and the mousepad is completely linear). because the drift from the counterclockwise circle cancels out exactly with that from the clockwise circle. for reference: the 3360/3366's dpi varies by about 1% for every 0.1mm difference in height (higher the mouse is above the pad, the lower the dpi) i have many many mice and mousepads that i'd be willing to donate/lend to you for testing. pm me on ocn if you're interested.

you should post this on ocn this is definitely the most interesting thing developed in the mouse community in the last few months some questions: 1. how fast can the thing move? 2. how sure are you that the motion is actually perfectly parallel to the mousepad? if there is a slight angle, because the mouse's actual sensitivity depends on the tracking height, there will be drift even for a perfectly accurate sensor. (in other words: a sensor that is perfect in every way except for having height-dependent dpi will drift if there is any angle between the plane of motion and the mousepad) one way to quantify this would be to compare dpi measurements (in the vertical direction) when the horizontal position is at the left, middle, and right. and vice versa for horizontal/vertical.

actually even with m_rawinput 1, setcursorpos is still being called (every frame i think) you can see this if you have a second monitor open; you can see the cursor bouncing on the second screen when you swipe with a high dpi and fps_max 60 i think this is so that you don't click on the second window too easily. but why don't they just call clipcursor? interesting; what are you using, obs? this is something i should definitely try when i resume my input lag measurements the csgo cursor gets the cursor position differently from the csgo screen movements though. for example if you use rinput, and set m_rawinput 1, in-game your crosshair is stuck and doesnt move, but the csgo cursor is still fine

try this https://drive.google.com/file/d/0B5_qzxdnJV0PdVJjdDFEd3BYNUk/view?usp=sharing

yea it's like that for everyone else. trying to figure out why...

kkkkkkkkkkkkkkkkkkkkkkk volz and i fixed the issues with m_rawinput 0 using a modified rinput here's a dll https://drive.google.com/file/d/0B5_qzxdnJV0PNDZsejlsTGFQUmM/view?usp=sharing < this was a debug build which doesn't work unless you have msvcr debug libraries and stuff https://drive.google.com/file/d/0B5_qzxdnJV0PdVJjdDFEd3BYNUk/view?usp=sharing source: https://github.com/abort/Rinput-Library or https://github.com/VolsandJezuz/Rinput-Library and replace rawinput.cpp with this: http://pastebin.com/Kjb7vWhj i guess volz will commit the changes to his fork when he sees this

hm... yea i just tried at fps_max 0 and it's not perfect... windows cursor leads by 2ms or so. doesn't necessarily translate into in-game latency though.

what's the framerate here? fullscreen or fullscreen windowed? how do you get both cursors to show up? ideally, if the game runs at infinite fps and there's nothing stupid going on (e.g. vsync), 1. the windows cursor and the game cursor should match perfectly at the top of the screen 2. the windows cursor should lag behind the game cursor by one refresh period (well actually refresh period minus vblank time) this is because the position of the windows cursor is determined at the start of the refresh cycle

well the highspeed camera tests i've seen before, including my own before i started the photodiode+mcu setup, are intrinsically are limited to ~1ms accuracy and precision because of 1000fps and the timing of physical events (whether it's motion or clicking a button). actually i'll do the teensy test as well. i'm not convinced that there's anything "wrong" with m_rawinput 1 that causes the 0.0x% deviations in the op. probably related to floating-point stuff

teensy2.0 does 1000hz fine with theur sample usb mouse code @volz: well i've never seen anyone but myself do the camera tests properly... they usually just look at a small region of the screen, so each measurement has +-(0.5/refreshrate) error.

if anyone can compile https://github.com/abort/Rinput-Library try this http://www.overclock.net/t/1545382/csgo-m-rawinput-0-drops-samples/190#post_24385831 damn it man idk how many times i have to say this i only got 1.5ms difference by underclocking my 4770k to 800mhz and gpu to whatever the minimum is in afterburner. this gave an in-game fps of ~90 in a server with no bots. the difference at my usual settings was 100-200us. dont remember precisely, but there was for sure a consistent difference.

hello, just wanted to let you know that i've noticed the same phenomenon here: http://www.overclock.net/t/1545382/csgo-m-rawinput-0-drops-samples no one really knows why, i guess it's due to the potential for a packet/motion event to arrive between the calls to getcursorpos and setcursorpos which is what source games use when m_rawinput is 0. how did you measure/estimate those numbers?