Optimized .exe; builds of ioq3 engine
With GoogleTranslate, Bumpy, dmaHD, iKALiZER, Raw Mouse, Bug Fixes, ..
#951
Posted 26 July 2010 - 08:09 AM
#952
Posted 26 July 2010 - 08:44 AM
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
- Optimized exe; builds of ioq3 engine for urt With GoogleTranslate, Bumpy, dmaHD, iKALiZER, Raw Mouse, Bug Fixes, ..
- Networking, lag meter, and gaming consistency guide
#953
Posted 26 July 2010 - 10:01 AM
mitsubishi, on 26 July 2010 - 08:44 AM, said:
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
#954
Posted 26 July 2010 - 10:12 AM
--
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
- Optimized exe; builds of ioq3 engine for urt With GoogleTranslate, Bumpy, dmaHD, iKALiZER, Raw Mouse, Bug Fixes, ..
- Networking, lag meter, and gaming consistency guide
#955
Posted 26 July 2010 - 12:06 PM
mitsubishi, on 26 July 2010 - 10:12 AM, said:
--
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 ^^
#956
Posted 26 July 2010 - 01:51 PM
- Optimized exe; builds of ioq3 engine for urt With GoogleTranslate, Bumpy, dmaHD, iKALiZER, Raw Mouse, Bug Fixes, ..
- Networking, lag meter, and gaming consistency guide
#957
Posted 26 July 2010 - 03:01 PM
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
#958
Posted 26 July 2010 - 03:06 PM
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.
#959
Posted 26 July 2010 - 03:41 PM
(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
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:
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
- Optimized exe; builds of ioq3 engine for urt With GoogleTranslate, Bumpy, dmaHD, iKALiZER, Raw Mouse, Bug Fixes, ..
- Networking, lag meter, and gaming consistency guide
#960
Posted 26 July 2010 - 04:38 PM
mitsubishi, on 26 July 2010 - 03:41 PM, said:
(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