User panel stuff on forum
  11 posts on 1 page  1
Client Talk
2013-04-16, 17:06
Member
73 posts

Registered:
Oct 2010
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)
2013-04-16, 18:22
Member
286 posts

Registered:
Sep 2012
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)
2013-04-16, 20:33
Administrator
1024 posts

Registered:
Apr 2006
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)
2013-04-16, 21:40
Member
286 posts

Registered:
Sep 2012
Mh yes my bad, though I used to play with such a low sens a while ago.
2013-04-17, 01:31
Member
2 posts

Registered:
Oct 2011
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.
[16:04] <Rauvz> dm4 is hell
[16:04] <Rauvz> dm6 is purgatory
[16:04] <princess_faerie> dm2 is the waiting room?
2013-04-17, 18:40
Member
73 posts

Registered:
Oct 2010
Thanks.
2013-06-11, 19:29
Member
73 posts

Registered:
Oct 2010
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.
2013-06-24, 12:50
News Writer
904 posts

Registered:
Jan 2006
Jissse wrote:
I'm not sure if there's the same problem in qw.

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

[edit: Raw input ftw ]
jezus! really 15cm? mine is like 6cm...
2013-06-24, 13:23
Administrator
1024 posts

Registered:
Apr 2006
dirtbox wrote:
Jissse wrote:
I'm not sure if there's the same problem in qw.

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

[edit: Raw input ftw ]
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
2013-06-24, 18:34
Member
383 posts

Registered:
Apr 2006
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!
2013-06-24, 18:40
Member
383 posts

Registered:
Apr 2006
VanoZ wrote:
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.


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.

Johnny_cz wrote:
Yes, please change your post somehow so that it doesn't confuse anyone, because in_mouse 3 in ezQuake really doesn't "Processes DirectInput mouse movement events", what you pasted is a description of an custom algorithm by id Software made on top of what we know as in_mouse 2.
  11 posts on 1 page  1