[Kendle]

Windows XP SP3 + G3 laser @ 1000dpi and in_rawmouse 1 works fine for me. Can't say it improves anything but it works without issue. Perhaps you actually need a high definition mouse for this to work / make a difference ?

[mitsubishi]

The main big fat difference I found which is in line with this good post by Obscure is that if in-game acceleration sensitivity is low it usually means mouse sensitivity is high and that will produce negative acceleration since internal cursor hits the edge of the window often and that process introduces delays. Of course, it will go away if driver sensitivity is set too low while DPI is still high. I do that anyway since without it in-game cursor (in UI) is very fast (on 5700). (I still don't know if that has drawbacks, meaning it will be better to have high DPI on high driver sensitivity but I wouldn't bet on it).

Other than that, there's theoretically higher chance to see lower latency since the path is shorter (and busier). Some people say they see it but I can't claim I do. It may be there and help of course, but I wouldn't be able to say "there it was! this wouldn't go like that without raw.".

--
directinput (in_mouse 1 (+ in_rawmouse 0 here)) also avoids negative accel but it has quirks and latencies (latencies also according to Microsoft).

--
The reasons Microsoft claims make raw input better for gaming.

This post has been edited by mitsubishi: 26 July 2010 - 10:18 AM

[versus666]

mitsubishi, on 26 July 2010 - 08:44 AM, said:

The main big fat difference I found which is in line with this good post by Obscure is that if in-game acceleration is low it usually means mouse sensitivity is high and that will produce negative acceleration since internal cursor hits the edge of the window often and that process introduces delays. Of course, it will go away if driver sensitivity is set too low while DPI is still high. I do that anyway since without it in-game cursor (in UI) is very fast (on 5700). (I still don't know if that has drawbacks, meaning it will be better to have high DPI on high driver sensitivity but I wouldn't bet on it).

Franckly I don't get it.
A long time a go I spent some of time studying game engine (mainly Q3) and the logic between sensitivity, DPI and screen resolution, so I'm quite puzzled when I read you:

"if in-game acceleration is low it usually means mouse sensitivity is high"
Ok, the user compensate the lack of acceleration but also loose a bit of accuracy. Understandable, why not ?

"that will produce negative acceleration since internal cursor hits the edge of the window often and that process introduces delays"
From what I remember the so bad named 'negative acceleration' is just the HARDWARE mouse sending too much datas to the HARDWARE buffer when moved fast so some moves are skipped and it seems like the cursor is slowing and/or jumping.
I'm even more puzzled when you talk about the 'edge of the window'... The data is processed by the engine and then decide if it should 'step' in ( m_pitch, m_yaw etc), I don't remember any kind of 2 dimensional system projection behaving like if a cursor was moving on the screen. And producing delays relative to an 'edge'... Do you have a link ?

"it will go away if driver sensitivity is set too low while DPI is still high"
Well... Isn't driver sensibility just the same than windows sensibility (being between mouse and Windows, but not providing any acceleration, just translating hardware DPI to software DPI)? Using low driver sensitivity with high mouse DPI is quite pointless don't you think ? Because faints movements would not be converted to pointer movements : you LOOSE accuracy on slight movements even though it seems more fluid with high speed movements.

Anyway "high DPI on high driver sensitivity" just seems to me like heresy : you get crazy uncontrollable movements AND a nearly total loss of accuracy, whatever the kind of movements you do (also I remember there was a fuss a year or two ago about a very high CPU usage due to high DPI mouse movements, I don't know if it's fixed now, my own simple tests show a very negligible impact on CPU usage, don't know if some mouse/systems are still affected).
Or I really missed something obvious.

This post has been edited by versus666: 26 July 2010 - 10:11 AM

[mitsubishi]

'if in-game acceleration is low' is a typo, I meant sensitivity.
--
To see negative accel punch you in the face, get a 5700DPI mouse on very high driver sensitivity[e.g. 'Speed' in Logitech settings] and try to move in game when game's sensitivity is low.
--
It can't be hardware-related only since it goes away on raw or direct input.
--
OS sensitivity is not respected in raw input according to Microsoft though it gets quirky if I choose 'use OS native drivers' in Logitech. Apparently it's not respected in raw if that option isn't checked and it's respected if it is checked. In non-raw it appears to go only with driver's sensitivity in those mice. It's quite confusing (and it doesn't seem standardized).

This post has been edited by mitsubishi: 26 July 2010 - 10:41 AM

[versus666]

mitsubishi, on 26 July 2010 - 10:12 AM, said:

'if in-game acceleration is low' is a typo, I meant sensitivity.
--
To see negative accel punch you in the face, get a 5700DPI mouse on very high driver sensitivity[e.g. 'Speed' in Logitech settings] and try to move in game when game's sensitivity is low.
--
It can't be hardware-related only since it goes away on raw or direct input.
--
OS sensitivity is not respected in raw input according to Microsoft though it gets quirky if I choose 'use OS native drivers' in Logitech. Apparently it's not respected in raw if that option isn't checked and it's respected if it is checked. In non-raw it appears to go only with driver's sensitivity in those mice. It's quite confusing (and it doesn't seem standardized).

So the negative accel you describe is just a buffer overflow ?

Logitech drivers are really a mess, I owed one, I saw the strange behavior with the driver, never installed it anymore, it seems they still haven't improved that in 10 year ^^

[mitsubishi]

The idea is that the quirk occurs when the internal cursor used on non-raw and non-directinput mouse has to recenter itself when it hits the edge of the window. Raw and Directinput do not use cursors of the desktop and hence they don't hit such edges. Other ways to reduce the effect is higher resolution since it has more pixels to move.

[versus666]

Is there a reason to use a will-fail-non-raw-nor-Directinput-method with an high DPI mouse, other than maybe an hypothetical compatibility ? I don't think any 'competitive mouse' would have a problem to run in RAW mode and 'basic mouse' with limited DPI won't get any advantage from RAW even if they do support RAW, so classic mouse support method is fine and do not fail... I don't see the problem.
Even if it's about mouse acceleration change between modes don't cl_mouseAccelOffset and cl_mouseAccelStyle can be used to fine tune ?

This post has been edited by versus666: 26 July 2010 - 03:08 PM

[p5yc0runn3r]

Mitsu, about the negative acceleration thing...I think I have an idea that you could try.
You are calling your modified SDL with raw mouse capture (WM_INPUT) from the ioq3-urt executable.

This could lead to buffer underflow where more data is read than given to the application. I suggest you have 2 variables for x and y and when you receive WM_INPUT and ioq3-urt did not call you yet from a previous WM_INPUT, you add the values to the x and y variables. Then, when ioq3-urt calls SDL, the x and y variables are given and then set to 0 again.

This will 'interpolate' the values in case the application is slower than the WM_INPUT messages.

[mitsubishi]

That's what it does. WM_INPUT is about 1000Hz here [while game 125] so the vars are "+=" till read and 0'ed. Well, they should be "+=" anyway since the client isn't in sync. I was even worried in case the whole process is not thread safe (needing some kind of 'trigger' var to protect it) but it seems to be ok with just "+= and then zero".

(At first there wasn't even "+=", just "send to queue", but it was a hell to protect it from queue floods:P) [queue floods due to loading screens, not the normal process itself.]

(the keys are similarly added in arrays)


--

Quote

Even if it's about mouse acceleration change between modes don't cl_mouseAccelOffset and cl_mouseAccelStyle can be used to fine tune ?

Negative acceleration here is not a feature, it's a quirk. It's not an easily quantifiable acceleration (to just be able to counter it with a number or just a calculation). The cursor (internally) just hits a wall and it loses information. The programmer can not know easily what exactly was lost so they can't easily counter it. If it was the case, there wouldn't be negative acceleration to begin with.

Well, that's the theory at least, I haven't looked at it first hand.

versus666, on 26 July 2010 - 03:01 PM, said:

won't get any advantage from RAW

You missed the basic paragraph about the feature: It avoids cases of negative acceleration but also is higher resolution/lower latency in cases. This is according to Microsoft.

This post has been edited by mitsubishi: 26 July 2010 - 04:07 PM

[versus666]

mitsubishi, on 26 July 2010 - 03:41 PM, said:

That's what it does. WM_INPUT is about 1000Hz here [while game 125] so the vars are "+=" till read and 0'ed. Well, they should be "+=" anyway since the client isn't in sync. I was even worried in case the whole process is not thread safe (needing some kind of 'trigger' var to protect it) but it seems to be ok with just "+= and then zero".

(At first there wasn't even "+=", just "send to queue", but it was a hell to protect it from queue floods:P) [queue floods due to loading screens, not the normal process itself.]

(the keys are similarly added in arrays)


--

Negative acceleration here is not a feature, it's a quirk. It's not an easily quantifiable acceleration (to just be able to counter it with a number or just a calculation). The cursor (internally) just hits a wall and it loses information. The programmer can not know easily what exactly was lost so they can't easily counter it. If it was the case, there wouldn't be negative acceleration to begin with.

Well, that's the theory at least, I haven't looked at it first hand.


You missed the basic paragraph about the feature: It avoids cases of negative acceleration but also is higher resolution/lower latency in cases. This is according to Microsoft.

I understand very well the problem with 'negative acceleration'.

What's the point of trying to use RAW with a low quality mouse like a DELL, 125Mhz USB polling rate, 800 DPI at best ?
Whatever the possible improvement in the processing of mouse input, *IF* the mouse allow the RAW method, it would be negligible given the specs of the mouse, don't you think ? And it doesn't produce 'negative acceleration' whatever the method used.

High DPI mouse have problem with some weird sensitivity settings on classic method ? Use RAW !
Use RAW and want accel ? Fine tune with cl_mouseAccelOffset and cl_mouseAccelStyle !
Have a low DPI mouse and can't use RAW ? Use classic method and don't bother !

I really don't see the problem.
Ok, having a method that sometimes don't works on competition mouse is a but frustrating but sometimes perfection is not possible, maybe it's just the method which is flawed and does not fit to extreme hardware input.

This post has been edited by versus666: 26 July 2010 - 04:39 PM