Despite what Microsoft's documentation claims, pointer acceleration isn't always desirable.That's an interesting detail that I didn't think of. I'm having trouble thinking of a situation where you'd want that though, do you have example?
Many people prefer to disable mouse acceleration for first-person shooters. See e.g. http://www.tomshardware.co.uk/faq/id-1953585/completely-turn-mouse-acceleration-windows.html and Google for more.
Many people prefer to disable mouse acceleration for first-person shooters. See e.g. http://www.tomshardware.co.uk/faq/id-1953585/completely-turn-mouse-acceleration-windows.html and Google for more.
For an FPS you'd most likely use a centered reticle and rotate the camera with raw input data. If that's not the case and the OP requires a ballistic free mouse pointer, I'd recommend having some sensitivity setting and apply that to relative mouse movements to position the (clamped) mouse pointer.
"The disadvantage is that WM_INPUT has no ballistics applied to its data, so if you want to drive a cursor with this data, extra effort will be required to make the cursor behave like it does in Windows. For more information about applying pointer ballistics, see Pointer Ballistics for Windows XP."
https://msdn.microsoft.com/en-us/library/windows/desktop/ee418864(v=vs.85).aspx
Too bad the pointer ballistics link is removed, though. Why do you want to use rawinput if you want the cursor position?
Ahh mouse acceleration, that makes sense!
I guess I could just use GetCursorPos() when I need the screen coordinates instead. (There are no hidden costs associated with it?)
I guess I could just use GetCursorPos() when I need the screen coordinates instead. (There are no hidden costs associated with it?)
GetCursorPos() gives you the actual screen coordinates while WM_MOUSEMOVE gives you coordinates relative to the client area. If you support windowed mode you'll want to use the latter. Multiple monitors might also be something you want to keep in mind.
