Due to information provided by razer support
http://help.razersupport.com/us-en/resolution.asp?sid=231822110527066249072089&pid=1451&pnm=Razer+Copperhead&seid=400002699&pos=Windows&top=&rid=26438
Direct input implementation (in q3.. topic is about q3) has a lag about 12ms, and non-direct input has not.
Do someone know if QW direct input has such lag or not,

And Fathers, Odin and Thor!!! What mouse settings do you have?
(in_mouse, DPI? and other tricky things)

I'm not sure if there's the same problem in qw.

In_mouse 3, 450dpi, 1000hz, around 15cm/360.

[edit: Raw input ftw ]

(Edited 2013-04-17, 08:04)

There is probably copy paste from q3 here and there in ezquake code base, or rather I know there is. However I don't think you can draw any conclusions like just because it might be true for q3, it would automatically be true for ezquake.

I think most people use raw input (in_mouse 3) in Windows. I use in_mouse 1 in Linux, however it's not the same as in_mouse 1 in regular ezquake, this XInput2 is not yet released in ezq.

Jissse: I guess you mean 360 degrees? (As in complete turnaround, not halfway)

Mh yes my bad, though I used to play with such a low sens a while ago.

from worst to best :

q3's -1 : the game checks the windows pointer for movements.
directinput : os polls the mouse then some data formatting is done, the game then reads what's in that buffer.
rawinput : os polls the mouse and the game deals with it.

No idea if they pulled those 12ms out of their ass or not. They could have meant a lot of things, the obvious one being a 8ms delay ( 125hz ) + 4ms to actually sort the data. Considering how dodgy their " answer " is I'd roll with that, which would imply a 2+4 delay at 500hz.

But anyway, it's still massively better than waiting for the os to poll the peripheral, slap the data in a buffer, draw the new pointer position, read that, slap it into yet another thread and then maybe finally doing something with it ingame.

Thanks.

Quote (Carmack):

in_mouse 1: Mouse control with standard win-32 cursor calls, just like Quake 2.

in_mouse 2: Mouse control using DirectInput to sample the mouse relative counters each frame. This behaves like winquake with -dinput. There isn't a lot of difference between this and 1, but you get a little more precision, and you never run into window clamping issues. If at some point in the future microsoft changes the implementation of DirectInput so that it processes all pending mouse events exactly when the getState call happens, this will be the ideal input mode.

in_mouse 3: Processes DirectInput mouse movement events, and filters the amount of movement over the next 25 milliseconds. This effectively adds about 12 ms of latency to the mouse control, but the movement is smooth and consistant at any variable frame rate. This will be the default for Quake 3, but some people may want the 12ms faster (but rougher) response time of mode 2.

It takes a pretty intense player to even notice the difference in most cases, but if you have a setup that can run a very consistant 30 fps you will probably apreciate the smoothness. At 60 fps, anyone can tell the difference, but rendering speeds will tend to cause a fair amount of jitter at those rates no matter what the mouse is doing.

DirectInput on WindowsNT does not log mouse events as they happen, but seems to just do a poll when called, so they can't be filtered properly.

jezus! really 15cm? mine is like 6cm...

I've always used about 20cm for 360 degree turn and I've had a pretty decent aim

15-20cm seems to be about the mean for quakeworld players. The range is quite vast, though. I knew a guy who played with 3cm/360. Reppie and Rikoll were down around 5cm when I last saw them asked, while bps played with 50cm!

I don't believe this is correct in the context of ezquake input methods. Here's an old quote from Johnny_cz on the topic.