http://msdn.microsoft.com/en-us/library/windo...85%29.aspx

tbh it feels strange in ql, like accel is flawed.in_mouse 1 feels much better tho.

Contrary to popular belief, raw input is not obtained 'directly' from the mouse in the way that you have suggested.

The game still has to ask the operating system to provide it with mouse input; it does this via the Raw Input API. The key feature of this API is that it promises not to scale, filter or otherwise modify the data it receives from the mouse - it just passes it on to the game as is. This is what is meant by 'directly'.

that was basically what i questioned, i even heard some people say that it does adress driectinput as well. i went on thinking if i can trash direct input completely from the operating system so that it has no part of the operating system at all... it seem the raw input is just another method (api) just like direct input. secondly, it was developed as a "rawer" type of input... i just wonder, whats underneath both of them, how does the operating system actually calculate mouse movement at its core...

thought if i could build a os that has the rawest form of input and cut every link in between, which is basically just designed to hold all the new features of the bunch of advanced 3rd party accessories that you can connect to your os. was thinking linux but read up on that and they got the same problem as windows... even when building your own distro you basically have to chose what option you have to go with, then there comes things like preference and what you actually in your own knowledge believes what is the most "right" implementation...

i have tried a bunch of things, in some ways those reg's that is "confirmed" to disable any trace of acceleration doesnt always result in what feels the best for you on a personal level, i think its more about preference and even if we find the optimal solution to have it like we think would be the best it might not end up as the best solution when it comes to actual performance.

Raw Input receives data on low level (and with device poll rate)
DirectInput is just high-priority thread that uses RawInput (means +some lag)
Win32API input applies user acceleration settings, can merge multiple moves into one event and other unpredictable stuff

The OS doesn't 'calculate' mouse movement. The mouse *measures* the movement, and then the OS asks for the results of these measurements at regaular intervals (polling rate). The raw input method is the rawest input, since it doesn't manipulate these measurements (counts), it just passes each sample to each application that is requesting raw input. The OS doesn't attempt to interpret or convert the measurements in any way. With other APIs, such as directinput, there is a certain amount of re-interpretation of the raw data, although this applies more to keyboard and gamepad input than mouse input.

The registry entries only apply to the desktop pointer scaling, it doesn't apply to raw input.

The whole point of an OS is that the applications *don't* access devices directly, otherwise every application would have to know how to access all possible devices that are ever created. The OS provides a standard by which applications can ask for input (via an API), and then the OS deals with device-specific interfacing, the details of which are provided by the device manufacturer via a driver, which is also standardised.

ok, so the mouse calculates the movements and sends it off to the api? in this case rawinput...

the mouse has a certain sensitivity value to it to start with without being connected to the interface... if you change the sensitivity in your windows mouse applet then you are changing the properties of it system wide or per application depending on which api its running and its no longer running on the properties of the mouse, that is what i mean with os calculations...

when you boot your system some part of the operating system tells it to behave like that, you dont actually change the values in your mouse... when you lower the sensitivity per application you cut even with odd numbers and are no longer running on the properties of the mouse... right?

yes. when you move your mouse around desktop, it is using Win32 functions, which call the raw input functions and apply your registry settings.

but its the same when you adjust sensitivity ingame if the game uses raw input...

not really. once the game obtains the input, it casts to floating point, so it's no longer limited to integer values.

thats what i mean injx. when the mouse operates on integer values and you set decimal values in the api it spits out floating point operation with values that the mouse in reality doesnt operate on.

this is not a problem.

maybe not a problem... but are there any api's or input methods that doesnt recalculate mouse output this way and leaves the mouse as it is? 1to1.... how do i find the sensitivity of the mouse to start with?

same? yes, it's the same because the mouse movement has to be interpreted somehow to be applied to the screen. somebody has to do it? the point is that only quakelive decides what happens.

Which input method is superior in your opinion?

While my new 120/125hz monitor shouldn't have much input lag (around 10-12ms according to testing tools), any minor change to graphical and or input settings are felt in game.

On source engine a combination of high frame rate + specific resolution feels more responsive to hand movement. (WM_MOUSEMOVE)

- Ticking raw input creates a sort of latency increase.
- Higher polling rate is more floaty.

I can solve these issues by decreasing + increase monitor/mouse refresh rate though.

ex:
120/125hz (around 8ms) monitor + 500/1000hz (2 or 1 ms max movement) mouse is "floaty" and almost unplayable.
125hz (8ms) monitor + 125hz (8ms max movement) mouse feels like my CRT.
100hz (10ms) monitor + 500hz (2ms max movement) mouse feels "okay"
etc...


A friend I know studying CS mentioned that implementation might be flawed, but If you have any input on the matter that would be great.

***Edit: I don't have this issue on my older 75hz LCD or CRT.

Technically speaking, raw input is better than pointer input in every respect. The two main reasons are:

1) Absolutely no windows sensitivity/accel manipulations, regardless of settings.

2) No negative accel due to the pointer hitting the edge of the screen.

But feel free to go with your "feeling" if you're happy with the result.

If the particular game/engine's use of raw input isn't very well implemented then you might want to avoid it, but any such claim is speculative without access to the engine's input code.

i agree about pluses, but one BIG minus is that floating oposite to in_mouse -2 and thats ruining whole this thing...

Sadly I have experiences that somehow go in the same direction. Back when RInput still worked for CSS after the first few OB updates, RInput felt smoother then CS Sources own m_rawinput method.

hi. seems you know what are you talking.
I have geforece m540gt in notebook. If I set settings in nvidia control panel @ adjust image settings , to QUALITY I get a lot lower sense in Quakelive. What can effect it? I am a bit lazy to check all settings one by one, but if you won't know, I will try to do that some evening. With ballanced and performance, sense seems like it should be. maybe its some antialiasng settings. I use it , to get nice grafix with 640x480 in quakelive.

why does raw input from q3 and ql differ so much?

duno eviili, maybe q3 calls different sets of the api and doesnt support some of the functions ql do... they did add a bunch of different new mouse settings to ql...

Didn't get anything from the discussion above. Please tell me If I might have some additional accel from Win7 using in_mouse 2?