Raw mouse input and alternatives.

[Gavin-Williams]

To handle full-screen scenario's I've switched to using raw mouse input via Win32, as I need hardware mouse deltas. But it seems to be getting overloaded by high mouse input polling rates. I think mice come installed at 1000Hz by default these days, so raw-input isn't fit for purpose. I've read that GetRawInputBuffer side-steps the windows message loop, removes the messages and can handle high polling rates. Is that true? And are there any other methods that are recommended? For example, what's the situation with XInput, DirectInput, or other mechanisms for getting mouse deltas?

If GetRawInputBuffer is a solution, is there a WindowsAppSDK equivalent?

[castorix]

GetRawInputBuffer removes the message from the Message Queue structure (MLIST mlInput) in Kernel
You can use GetRawInputBuffer with WinUI (P/Invoke in C#)
From MSDN, it is the best method :
' the best method to receive high-definition mouse movement data is WM_INPUT.'
https://learn.microsoft.com/en-us/windows/win32/dxtecharts/taking-advantage-of-high-dpi-mouse-movement

[Gavin-Williams]

I'm already using WM_INPUT and it doesn't work correctly, so that advice must be stale or incomplete. I will go through that article again and check if there are any issues with my code. But I've had to drop my mouse report rate to 250 Hz to stop the stutter.

[DarranRowe]

What definition of "work correctly" are you using? Remember, RegisterRawInputDevices only states that it will register a HID device for delivery of WM_INPUT messages. WM_INPUT only provides raw input data. If you are getting WM_INPUT messages for the device that you registered, then it is working correctly.
The big issue with anything sent as a window message is the simple fact that it gets processed in the message pump along with all of the other messages for that thread. This would mean that the WM_INPUT message is fighting against a lot of other things. What's worse, GetMessage ranks input messages below sent and posted messages. This kind of information is important because for frameworks such as WinUI 3, the dispatcher queue is implemented as a window, async call completion ends up getting posted to a window on the thread that it originated and much more.
As a side note, a raw Windows API application with very little processing is able to get 1,000 WM_INPUT messages a second with a high poll rate mouse. So the throughput of the messages in the message queue is important. If it is saturated, then you are going to have problems.
Also note, raw input is a per process thing. As RegisterRawInputDevices states:
"Only one window per raw input device class may be registered to receive raw input within a process (the window passed in the last call to RegisterRawInputDevices)."
So have you tried starting up a new thread with a very light weight message only window to handle input?

As a final note, IIRC the best performing input available for PC is GameInput from the GDK.

[Gavin-Williams]

When i say 'doesn't work correctly' - I mean that it seems like many mouse movements are being lost and not passed to WM_INPUT. I'm seeing extremely stuttered camera movement. My definition of a correctly working mouse API is one that can actually do the job of collecting mouse input and reporting it. It's a kind of simple definition.

I will look into using GDK. Though, I can't imagine MS have provided a .net wrapper and I just don't see myself being able to use it.

Though, I am surprised to find this page ... https://learn.microsoft.com/en-us/gaming/gdk/_content/gc/get-started-with-pc-dev/get-started-with-custom-engine/gc-get-started-with-custom-engine-pc-csharp ... that is wildly considerate of MS and completely out of character to give a nod to C# game dev.

[DarranRowe]

I mean that it seems like many mouse movements are being lost and not passed to WM_INPUT.

Are you sure though? If you are relying on a Window's message handling to process the message then the message queue not being drained in time will cause similar issues. Why do you think any kind of game input processing polls the input device outside of the message pump?

My definition of a correctly working mouse API is one that can actually do the job of collecting mouse input and reporting it. It's a kind of simple definition.

Again, are you sure that this isn't happening already? Have you been counting the input messages being sent to the window?
When just measuring the throughput of these message, I see very little in the way of Windows failing to send the input messages. For two examples:

This is my primary mouse with a pretty low polling rate. 115-125 hardware message per second is about what I expected from it.

This is from a high polling rate mouse. It averages out to over 1,000 input messages a second. What's more:

The CPU usage for the process was registering as 0. The message pump logging that I also have indicates that GetMessage was sleeping too, meaning the message queue was empty. Without setting up anything more complex, a window has enough throughput to handle high poll rate mice. So my thought here is that the message pump for the thread you are having input sent to is struggling, either due to it being saturated or because you are not completely handling all of the events in a timely manner.
The best thing to try is to move your input processing onto a dedicated separate thread.

[Gavin-Williams]

Maybe I don't understand how the win32 loop works. I might have just been lucky that it was working at all up till now.

I'm working out how to use PInvoke and COM interop, so that I can use the GameInput API.

[castorix]

I'm working out how to use PInvoke and COM interop, so that I can use the GameInput API.

I did a quick test (just XGameRuntimeInitialize + GameInputCreate then IGameInput.GetCurrentTimestamp to test a simple method) and it only works in x64, the "GameInput Service" must be installed too and I had to add a MicrosoftGame.Config file (otherwise I get E_GAME_MISSING_GAME_CONFIG error)

[fredemmott]

GameInput appears unsuitable for use in the Windows App SDK due to the license: microsoft/GDK#72

If it were part of the Windows App SDK, it would be a violation of the license terms to use the Windows App SDK in many apps that currently do, unless the GDK were relicensed by Microsoft.

[DarranRowe]

Hmm, well, I'll just edit this completely to revise the post.

According to the March 2024 release:

Although the runtime is included in Windows May 2020 Updates and later, running the MSI will ensure that you have the latest version.

In otherwords, the GameInput is distributed as part of the CUs for all supported versions of Windows. This means for supported versions of Windows, you should use the 26100 version of the SDK, then the only license that you need to worry about is the Windows SDK license.

It is only really some of the older versions that could be a problem here. This is because of the presence or lack thereof, of the GameInput libraries. If they got a CU after May 2020, then it could be that they have a version of the GameInput library. But it will be useful if there is a release of the redistributable with a license closer to the Windows SDK redistributable license.