Hi, I've got raw input working for mouse input in my thing and it works great for delta-based input (high-res mouse movement). For the GUI system, I'm just using GetCursorPos in the mouse button event handler to get the position of the hardware mouse (to do hit-tests against buttons, etc). This works, however there is is often a problem with the delay between the user actually pressing the button and when the event is pulled off the event queue by the scripts. This especially manifests itself when the FPS drops a bit and player tries to drag and drop a UI element - they click on the icon in the GUI and start dragging but by the time the GUI event handler script gets called for mouse-down, the actual position of the hardware mouse cursor is now outside the icon so the hit test fails (and the drag operation doesn't start). In other words, the GetCursorPos result is different to when the physical event actually occured. Now, WM_LBUTTONDOWN solves this problem by passing in the mouse position for when the event actually occurred, so I wanted to use this paradigm and pass position info with the button event to the scripts. Unfortunately WM_INPUT is pre-ballistics so calling GetCursorPos at that time isn't going to be accurate. In any case, there can still be a processing delay between the actual time the user pressed the button and when the WM_INPUT is pumped out of the window's message queue... So - my question is, is there any way to get a message queue syncronised position of the mouse in the Windows API? Kind of like how GetKeyState is syncronised, but instead it would be for mouse position....or am I barking up the wrong tree here? Cheers, Thomas

You might be able to use buffered raw input rather than the standard unbuffered read to achieve what you want.
I you're in for a world of pain though, by trying to get the bennefits of WM_LBUTTONDOWN, without actually using WM_LBUTTONDOWN itself.

Quote:Original post by cow_in_the_well
So - my question is, is there any way to get a message queue syncronised position of the mouse in the Windows API? Kind of like how GetKeyState is syncronised, but instead it would be for mouse position

GetMessagePos is what you describe. Despite the blurb it does also work if your message loop is PeekMessage based.

Personally I've been pretty satisfied when I realized that the two inputs, although coming from the same device, are different.

Just as I manage the keyboard using a button-based approach (for 'action') and a character-based approach for text input, mouse can either generate raw input or cursor-position input. They're truly two different inputs. All components consuming mouse-cursor input will get only mouse-cursor input. All components managing movement-like input do get the raw input without any sort of ballistics.

If you think about it, it doesn't truly make much sense to do otherwise: the standard WM messages are just fine for GUI stuff, as the pixel is a quite accurate approximation when a pointer is involved. It doesn't make much sense to drop ballistics when simulating a GUI - in 2009 one could even question the need to simulate a GUI in the first place to a certain degree.

Think at it again. Why do you need hi-precision raw input? Because at high framerates, rendering landscapes looks quite smoother, as the minimal - say 1/16 pixel - step involves a real deal of pixels changing (perception problem). Does the problem exist for GUI work? No. Supposing there is, what does an "half pixel" mean in GUI-like interaction? Supposing a meaning can be estabilished, the presentation to the user will either be subtle or unintuitive. How can this interaction capability be exploited?

Think at it more, by helping me thinking. Can you see a component consuming both inputs? Can you think at a component consuming both and truly mangling them together in a useful way?

No, I don't seriously think there's true need to mix and match hi-precision raw input with standard messages. In my opinion, the need to mix and match hi-precision raw input with cursor ballistics isn't completely there.

Hey thanks for the replies - thought I'd let you know what I ended up doing.

a. For mouse buttons, I switched to simply using WM_LBUTTONDOWN/UP, etc. These messages pass the mouse position when the event occured, and moving to these messages was pretty trivial (only complication was I have to SetCapture to make sure the game client gets the mouse ups).

b. Still use WM_INPUT for mouse moves (to get high res input), however to attach a mouse position to the mouse move events (with proper ballistics applied) I grab WM_MOUSEMOVE and attach the provided position to the most recent mouse move event from WM_INPUT (since multiple WM_INPUT raw mouse move events received in a single frame are accumulated into a single MouseEvent structure this works well).

c. For keyboard button events I use GetMessagePos (thanks, it was just what I was looking for!). I do this since mouse button and keyboard button events share the same KeyEvent structure.

So it's a mix of raw and windows messages which I think gives the best of both worlds.

Cheers,
Thomas

Quote:Original post by cow_in_the_well
So it's a mix of raw and windows messages which I think gives the best of both worlds.

You're doing pretty well if you don't end up with the worst of both! [grin]

Good to hear you have a solution.