[Old account 2.f4]

some thoughts from experience

in_mouse -1 is very bad if you are low-sensitivity player
i had logiteh mx518, and razer deathadder
and quite low sensitivity, below 1.0 with 900 DPI.

i couldn't do fast 180 degree turn in fast way, (like passing this jump before "Jackie Chan stairs" on ut4_trickmap: very fast 3x180) cursor did strange things.

and i was very dissapointed (best mice on market failed, like "WTF? it should do 4m/second without malfunction)

anyway in_mouse 1, fixed this.

[Infntnub]

2.f4, on 02 April 2010 - 09:06 PM, said:

some thoughts from experience

in_mouse -1 is very bad if you are low-sensitivity player
i had logiteh mx518, and razer deathadder
and quite low sensitivity, below 1.0 with 900 DPI.

i couldn't do fast 180 degree turn in fast way, (like passing this jump before "Jackie Chan stairs" on ut4_trickmap: very fast 3x180) cursor did strange things.

and i was very dissapointed (best mice on market failed, like "WTF? it should do 4m/second without malfunction)

anyway in_mouse 1, fixed this.

That is absolutely GREAT info for me, I have an mx518 due to arrive anyday.

I still wonder if -1 will still feel better in q3 with that mouse, since the one I current have is an mx310. Time will tell me that part though.

[Mod ObScUrE]

2.f4

Quote

some thoughts from experience

in_mouse -1 is very bad if you are low-sensitivity player
i had logiteh mx518, and razer deathadder
and quite low sensitivity, below 1.0 with 900 DPI.

i couldn't do fast 180 degree turn in fast way, (like passing this jump before "Jackie Chan stairs" on ut4_trickmap: very fast 3x180) cursor did strange things.

and i was very dissapointed (best mice on market failed, like "WTF? it should do 4m/second without malfunction)

anyway in_mouse 1, fixed this.

Windows tries to set the cursor in the center of the screen and when you move your cursor fast you get the edge clipping effect.
-1=Windows Pointer Input (edge clipping on high dpi or low resolution)


Mitsu
the problem that I had with 'in_mouse 1' was that I couldn't use it with higher polling rates.
so I had minimum the default 8ms latency + the buffering from directinput.

hey mitsu you could try now to implant /in_mouse 3 in your build

ESR-Source

Quote

1) Raw mouse input has no negative acceleration which is present in standard windows mouse input (in_mouse -1) due to low resolution, high mouse speed or high DPI of the mouse.

2) Raw mouse input has no positive acceleration in comparison to standart windows input because there is no pointer ballistics applied to it. This means that there is no CPL mouse fix needed to be applied if you use this type of input.

3) Raw mouse input uses unbuffered, immediate mouse data. This means that in comparison to DirectInput it has less input lag.

In_mouse 3 / Raw Input

MaJ, on 19 May 2009 - 08:08 PM, said:

"in_mouse 1", using DirectInput, is buffered. It isn't just grabbing the current coordinates coordinates of the mouse on the screen like "in_mouse -1" does. "in_mouse -1" simply grabs the mouse coordinates, figures out the change since the last time it grabbed them, then resets the mouse to the center of the screen again. This "in_mouse 3" hooks the mouse using Windows API calls and gets the raw data from the mouse.
What does this mean?

• DirectInput with newer mice can fill up the buffer in a hurry. -
  Yes, DI was not designed for your fancy 500-1000hz laser mouse. This causes missed clicks or buttons that "stick down".
  
  
  
• DirectInput introduces a delay in mouse input of ~12ms as it buffers the input....a small delay.....but it's there.
  
  
  
• "in_mouse -1" with a high sensitivity mouse can cause the mouse to hit the edge of the screen causing a sort of "clipping" in which your mouse sensitivity is effectively capped lower than it should be. -
  Lowering system mouse sensitivity and raising in-game sensitivity should fix this.
  
  
  
• "in_mouse 3" is not effected by system sensitivity and accelleration because it doesn't care about screen coordinates like "in_mouse -1".
  
  
  
• "in_mouse 3" does not exhibit "clipping" as there is no screen edge to hit and stop the mouse.
  
  
  
• "in_mouse 3" has no acceleration by the system. If you have come to rely on system accelleration you will have to tweak your cvars (cl_mouseaccell) to get the same feeling.

Imagine that, DirectInput, a Microsoft creation kinda sucks.......who would have thought? :-D

This post has been edited by ObScUrE: 03 April 2010 - 04:48 AM

[mitsubishi]

what buffering? citation needed.

[|WC|MojaveRattle]

Infntnub, on 02 April 2010 - 09:26 PM, said:

That is absolutely GREAT info for me, I have an mx518 due to arrive anyday.

I still wonder if -1 will still feel better in q3 with that mouse, since the one I current have is an mx310. Time will tell me that part though.

Just noting that the MX518 probably wasn't the best choice. Since the plastic like material on the top tends to "junk" up a lot. It would be a 5/5 in my book if the casing was made out of the rubber material used on the sides.

[mitsubishi]

it doesn't do anything at all.

source: source code.

This post has been edited by mitsubishi: 07 April 2010 - 09:43 AM

[Infntnub]

mitsubishi, on 07 April 2010 - 09:23 AM, said:

it doesn't do anything at all.

source: source code.

I don't like to doubt you or the source code, but if you try a value of 1 and then try -1 and just keep bouncing back and forth for example, you cannot tell me it doesn't do anything.



At the very least I would say there is a noticeable difference in the different settings.

[mitsubishi]

Do you run it through wine?

Because it doesn't exist at all for linux code-wise.

It does absolutely nothing at all.