Things you should know about Windows Input, but would rather not

> Games can probably get away by listening for the scan codes of the keys in the position commonly used by WASD, but it's a bit fragile, and they can't actually tell you what's printed on the keys they're listening to. The lack of consistenency is certainly annoying, though...

The operating system knows how to map scan codes to characters based on the keyboard mapping the user has selected.

    Win32: MapVirtualKeyExA / MapVirtualKeyW
    MacOS: CGEventKeyboardGetUnicodeString / UCKeyTranslate
    Linux: xkb_state_key_get_utf8

Stop reading character codes directly, use the scan code and when displaying them map it using the system API so people see the right freaking binding. It's not rocket science,

Scancode vs character code is what they are describing:

Games SHOULD use scancodes for positional mappings (like WASD) and rely on the system keymap to decide what letter to display them as. There is no "probably" here, the scancode is the scancode and the keymap is the keymap.

Games OFTEN use the character codes directly regardless if it's for a positional mapping or not. This requires explicit support in the game for each possible system keymap, otherwise you end up with nonsense mappings.

Option 1: remember to press Win+spacebar before launching game

Option 2: launch game, navigate to settings, write down on a sheet of paper what the current keybindings are (since one I press "." for "e" it's going to either whine or blank out whatever "." was mapped to when I started), repeat that exercise about 25 times per game, times the 15 games I have in rotation right now, feel that was a great use of my "downtime"

Option 2 has the added bonus of making it 50/50 whether the game help text knows I remapped, and thus says "press . to open door" or whether it continues to say "press e to open door" and I have to guess whether it means "their e" or "my e"

I am very lucky that Win+spacebar switches, so it's low drama to execute, just some drama to remember. Insult to injury, and likely very related to the article's points: if I remember after launching the game, Win+spacebar is 50/50 on whether the game notices and thus I usually just pay the startup cost again if I forget rather than having things be in limbo

I never said it would. Any engine needs 'basic platform support' style input. And going into extra windows/threads/apis is for 'competitive shooter titles'.

After working on one a bit I would say library way is not good enough :) but it is sure thing cost effective way to support a platform. Or even few platforms shared by same vendor.

Thank you for the suggestion. It's an interesting project, but I'm more comfortable writing Rust code. Also I still have a lot to do for the library I'm maintaining. The libei and Wayland support is still experimental and buggy and I need to get better integration tests working. So much to do, so little time :-)

Of course: https://crates.io/crates/enigo

Just wanted to check: what are the messages that cause the problem, exactly? If it’s only WM_MOUSEMOVE and WM_NCMOUSEMOVE, then it’s important to note that they do not, in fact, become real messages[1] until you GetMessage or PeekMessage:

> When the hardware mouse reports an interrupt, indicating that the physical mouse has moved, Windows determines which thread should receive the mouse move message and sets a flag on that thread’s input queue that says, “The mouse moved, in case anybody cares.” (Other stuff happens, too, which we will ignore here for now. In particular, if a mouse button event arrives, a lot of bookkeeping happens to preserve the virtual input state.)

> When that thread calls a message retrieval function like GetMessage, and the “The mouse moved” flag is set, Windows inspects the mouse position and does the work that is commonly considered to be part of mouse movement: Determining the window that should receive the message, changing the cursor, and determining what type of message to generate (usually WM_MOUSEMOVE or perhaps WM_NCMOUSEMOVE).

The book version of Raymond Chen’s blog[2] elaborates on the subject of messages arriving in an empty forest:

> One of [the] special messages is the WM_MOUSEMOVE message. As you saw earlier, the message is not added as an input message when the mouse moves; instead, a “the mouse moved” flag is set. When the window manager goes looking for an input message and the “the mouse moved” flag is set, it clears the flag and generates a WM_MOUSEMOVE message on the fly, adding it to the list of input messages (or coalescing it with an existing WM_MOUSEMOVE message).

> Other special messages that fall into this “generated on the fly” category are the WM_PAINT, WM_TIMER and WM_QUIT messages. The first two messages are generated even later in the message search process, only after no applicable input message list was found, and only if the message filter indicates that that type of message is being requested. (The WM_QUIT message is even shier than the paint and timer messages, because it emerges only after the posted message list is empty. On the other hand, the WM_QUIT message is also bolder, in that it ignores the message filter.)

Keeping that in mind, using PeekMessage() and thus materializing the pending WM_MOUSEMOVE should be done very carefully (though with PM_REMOVE it shouldn’t be a problem). In fact, it seems like unless you care about WM_TIMER, WM_PAINT, or WM_QUIT, the right thing to do upon seeing a WM_MOUSEMOVE (but not a WM_NCMOUSEMOVE) would be to behave as though the message queue is currently empty and proceed to do whatever other processing you need to perform for the current frame.

Still, I don’t get why this should be a problem. If you receive a WM_MOUSEMOVE and your only action is to discard it, surely it doesn’t take 125 μs to do that? And if it doesn’t, you shouldn’t see more WM_MOUSEMOVEs that can only get generated at 8 kHz at most.

Suggested experiment because I don’t have a fancy mouse: if you insert

  if (msg.hwnd == <root window> && msg.message == WM_MOUSEMOVE) continue;

[1]: https://devblogs.microsoft.com/oldnewthing/20031001-00/?p=42...

[2] https://openlibrary.org/works/OL9256722W

I guess if mice are generating too many messages, asking Windows to coalesce them has less impact.

It was pretty easy to find with the Settings app.

"Find a setting" > type "joy" suggests "Setup USB game controllers". Lists the controllers/joysticks. Click "Properties". Click "Calibrate..."

A timestamp won't help if your goal is reducing game lag. You can tell you're lagging, but can't do anything about it.

The Google IME is waaaay better. With both I have some bug though where the browser will just freeze for a few seconds while switching the IME - happens in both Chrome and Firefox. Also happens on macOS with the native IME so there seems to be some bug there...

Even if you do generate legacy input events, it is worth noting that the kernel still knows that they're not real input events. It seems to keep track of the current event on a per-thread basis (maybe it's stuffed into the TIB or something, but it could also just not be visible, I didn't search too deeply.) The knock-on effect of this is that sometimes DefWindowProc won't do the expected thing if you feed it a synthetic event, which could lead to strange behavior. You can of course use CreateSyntheticPointerDevice[1], and try to emulate it like that, but obviously then it knows that the events are coming from a synthetic pointer device (which is also system-wide and not just per-application!) So it feels like any way you go, behavior will be slightly different than expected.

Will this matter? I'm not quite sure.

I think Microsoft's WebView2 component enables Mouse-in-Pointer mode using the undocumented syscall for doing it per-HWND, but apparently Raw Input is per-entire-process, so if you aren't generating "legacy" events, will a WebView2 component in your process function as expected? Maybe if you go the synthetic pointer route, but again, that's a pretty big can of worms in and of itself.

Windows input is indeed very tricky. Seems like there's only one way to figure out some of these answers. Perhaps I should add RawInput to my test application and find out what the interaction is.

[1]: https://learn.microsoft.com/en-us/windows/win32/api/winuser/...

It's more complex than that. There's no right answer and therefore every answer is wrong :(

For more critical observers, you're right: raw input is preferred. However, most users (casuals) expect similar settings as their OS. It's probably best left up to the user to decide, but to default things to the OS legacy settings. A more advanced player will know to tune the settings while the less advanced just want to launch and go.

I'd argue that linear camera movement with mouse _is_ the expected behavior for FPS these days.

Surely even in a shooter game you spend some amount of time in menus where you do have a cursor, right? Is this why I sometimes get completely 'wrong' cursor movement in games?

Only when a raw input device is enabled. If I remember correctly, Windows will also send the raw input as legacy input messages. With no raw input device registered, the OG message queue is not bloated.

Thank you; I will try.

Keyboard repeat is only useful in ANSI terminal games on Unix, and games on some old 8 bit home computers that didn't have up and down events (Apple II+, ...).

A game written for an IBM PC and everything after that can know exactly which keys are being held down and when they are released by intercepting the "scan codes" (or abstract keyboard events in a GUI event loop).

All that is missing is synthesizer-like velocity and pressure info. :)

> will slow down typing significantly

Only for people who have to look at the screen. :)

The hunt-and-peck beginners who look at their fingers are not effect, and neither are those who can look at something else or close their eyes.

A serious concern affecting even those people is that using the release event could reorder things, causing mistakes. Like say if someone types the sequece wh (involving two hands) such that they release the w later than h.

> If you press one first it will register first.

While that is obviously so, there are two events: a press and a release event.

The thing I run into is that the release time: Shift being held over too long, into the start of the next character. Now comes out as NOw because the up event for Shift comes after the down event for w.

So I don't think my proposals are necessarily the right ones.

Perhaps this: when a shifted letter is being typed (the down event came in a shifted state), then the rule should apply that an up event should be received to generate the keystroke, and that up event should still be in the shifted state.

Refinement: when a shifted letter is being typed in a situation where the Shift was held over from a previous shifted letter, then apply the logic. Thus N is not delayed; it comes out on the downstroke. But if Shift is still held while o is typed, that is a held-over Shift, and so the rule applies; the state machine must see an up event for the o and then decides whether it is shifted. If Shift is released before the o, then o is issued on the down event as usual.

Another idea: when a shifted letter is being typed in a Shift-holdover state, then issue the keystroke for the letter either on the release of the Shift, or the release of the letter, whichever comes first. If Shift is released first, assume it was a holdover and don't capitalize the keystroke. If the letter is released first, issue the capitalized keystroke. In the situation where the intent is to type Now, this will hardly result in a noticeable delay for the o, since the Shift hold-over period is very brief.

> you can't have auto-repeat

Auto-repeat is an arbitrary behavior that kicks in due to a timer going off while a key is continuously held down.

It generates multiple fake keystrokes even though there aren't multiple down events.

So of course you can still have it generate multiple keystrokes even though there aren't multiple up events (including generating the first keystroke in spite of there not being any up event).

Also they probably ended up where they were because if I remember correctly windows will 'smash' mouse move events together for you in some cases. This will look like 'lost messages' (I recognized the peek loop as I have done that same thing once). This is is for two reasons one old not needed as much any more, and the one they found out the hard way. Memory as just scrubbing the mouse around would create a ton of memory objects that need to be pretty much cleaned up right away. The second is performance. As that is a ton of little messages that need to be picked up looked at and something done with. Which zorches your CPU.

The core of the issue is trying to wrap polling style of logic into an event based system (which windows is at its heart). There is no real pretty way to fix it.

This is distinction without difference imho. 8 thousand messages is 320KB. My magic estimator tells me this would take about 25 microseconds to process on a very shitty by now i3 7100.

No they aren't.

Please, 120 Hz monitors and "high end" mice are the PC gaming equivalent of audiophile equipment. Provides no actual benefit other than the user believing in it.

LMAO, Rome fell much faster ;)

I think it's only been with new DX12 presentation modes [1] that games can use "Borderless windowed" without input lag. Before that or without updated support, you would always get a noticeable amount of input lag when not using exclusive fullscreen. I played CSGO competitively for a while, and it was definitely enough to be annoying.

[1] https://learn.microsoft.com/en-us/windows/win32/direct3ddxgi...

>That's odd, because in my experience almost all games run best in "Borderless windowed" mode.

I think the difference is between when you tell the game to run that way in it's settings, versus abruptly forcing it by doing alt-tab. Games where their default 'full screen' is really 'borderless windowed' don't have problems when you alt-tab, but a lot of them act weird when their 'full screen' actually is a true full screen mode and you force them out of it by alt-tabbing.

I personally don't mind having it installed, just because it makes a huge difference.

I remember playing CS:GO (and later, CS2) and it was super common to see cheaters in almost every other match.

In contrast, I haven't seen a single cheater yet in a match of Valorant.

You can see the difference yourself by checking the UnknownCheats forums for CS2 vs Valorant: the CS2 subforum is full of new hacks every day (most of which seem to be slight modifications of existing ones) while the Valorant one is completely dead.

The sad reality is that people simply do not give a damn/are so weak willed that they will buy the game regardless. I wish it weren't the case, but unfortunately it is.