Originally Posted by qsxcv
Originally Posted by Skylit
Raw input: This is API that buffers mouse movement independent of frame rate. Traditionally, games like counter strike, early quake, ut. etc.. rendered mouse input by center grab repositioning or WM_MOUSEMOVE. Raw input in layman's terms reads information from your mouse directly (inc. polling) and translates 1:1 DPI settings to game. Mouse fix or windows settings need not apply.
Controversy over added input latency or smoothing effect reported by users: Raw input regardless of game engine will almost always buffer polled rate faster than that of the average frame rate you pull in game. There may be an “unconnected” feeling for many users as movement is no longer based on in-game fps.
can someone explain this to me?
from what i know you always have the following situation:
when game needs input (start of frame):-1----------------2-----------3------------4
ideally, what the game uses for mouse movement at frame 2 is c+d; at frame 3, e; at frame 4, f+g; ...
how is raw input different at all for this?
I don't understand it. It's not really any different, I think. The logic in the program seems to be the same. You still have a "window" that receives an event, except it's raw data instead of data about a mouse pointer.
In practice, if you think about how C code for a Windows program looks like, it really looks very similar in both cases. There is a loop that calls a function to ask Windows for new messages and will dispatch it to the "WndProc()" function of the window you registered. Inside your WndProc() there's a large switch statement dealing with events. The difference between normal and raw will be you using a different case statement to look at a different event. There's the WM_MOUSEMOVE event for the normal mouse pointer, and there's a WM_INPUT event for raw data.
So in that ASCII art you drew, you might want two threads in your program. The one dealing with your window will call GetMessage() of Windows and will block and then get woken up at points a b c d e f g. Then you'll do that c+d and f+g stuff you imagined yourself. The other thread hitting the 1 2 3 4 points sets things to zero.
If you don't do a separate thread, you can look for messages with PeekMessage() instead of that blocking GetMessage() whenever you've finished painting your frames. What I understood will happen is that you'll see that you have a whole bunch of them instead of just one. You'll still get to do the c+d and f+g stuff.
Perhaps the quote is really talking about DirectInput where it says "raw input"? DirectInput is not supposed to be used any more in the future as far as I know, is deprecated by Microsoft. DirectInput created a separate thread that dealt with the message stuff and window events for you.
Something else that's interesting is that the polling for the USB mouse is invisible to the CPU and OS. This is really done by the USB host controller. The controller will then only send an interrupt signal to the CPU if it has new data to present, so from the point of view of the CPU there is never any waiting like what you normally imagine if you hear "polling".Edited by deepor - 12/9/14 at 4:17pm