Comments on: Input for Modern PC Games [...] Don’t forget to check this essay from Keith Judge about submit doing for PC games here: /2011/04/25/input-for-modern-pc-games/ [...] [...] Don’t forget to check this essay from Keith Judge about submit doing for PC games here: /2011/04/25/input-for-modern-pc-games/ [...]

]]>
By: Arseny Kapoulkine/2011/04/25/input-for-modern-pc-games/#comment-5772 Arseny Kapoulkine Fri, 17 Jun 2011 18:00:53 +0000 A few additional things worth mentioning: * On modern versions of Windows, DirectInput for keyboards is just a layer on top of WM_INPUT. IIRC on older (XP and previous I think) versions, DI could be a bit more 'direct' when a suitable driver was present. * Raw input (WM_INPUT or DirectInput) bypasses things like key delay/repeat and will only give you input from the physical keyboard device... * ...which brings me onto a simple piece of advice: NEVER use raw input for text input, it should only be used for game control input... * ...for text (entering player names, chat, etc), always use WM_CHAR. It has a higher latency than raw input (which is why you want to use raw for gameplay control), but for that overhead it provides a lot of things there's no benefit of reinventing yourself, including: - mapping through a keymap to show what sticker the users key has on it (A versus Q in the discussion above) - key repeat/delay - modifiers like shift, caps lock, alt, etc - dead key characters. To get accents, umlauts and the like above letters, some continental European key maps require typing two characters, first the dead key for the appendage, then the base character, they come through as two key presses - Input Method Editors (IME) for languages like Japanese - Built in accessibilty features like StickyKeys - Third party accessibility programs and devices, e.g. speech input, predictive text software A few additional things worth mentioning:

* On modern versions of Windows, DirectInput for keyboards is just a layer on top of WM_INPUT. IIRC on older (XP and previous I think) versions, DI could be a bit more ‘direct’ when a suitable driver was present.

* Raw input (WM_INPUT or DirectInput) bypasses things like key delay/repeat and will only give you input from the physical keyboard device…

* …which brings me onto a simple piece of advice: NEVER use raw input for text input, it should only be used for game control input…

* …for text (entering player names, chat, etc), always use WM_CHAR. It has a higher latency than raw input (which is why you want to use raw for gameplay control), but for that overhead it provides a lot of things there’s no benefit of reinventing yourself, including:
- mapping through a keymap to show what sticker the users key has on it (A versus Q in the discussion above)
- key repeat/delay
- modifiers like shift, caps lock, alt, etc
- dead key characters. To get accents, umlauts and the like above letters, some continental European key maps require typing two characters, first the dead key for the appendage, then the base character, they come through as two key presses
- Input Method Editors (IME) for languages like Japanese
- Built in accessibilty features like StickyKeys
- Third party accessibility programs and devices, e.g. speech input, predictive text software

]]>
By: nicolas mercier/2011/04/25/input-for-modern-pc-games/#comment-3243 nicolas mercier Tue, 26 Apr 2011 14:01:46 +0000 OK, so it looks like (other than Pause/Break), the only remaining issues are that some Japanese keyboards have tricky behaviour to deal with (some keys act as a toggle at the hardware level). I still prefer the Raw Input API as the code is a lot cleaner and simpler than DirectInput and doesn't create a second thread to process messages. Why is Pause/Break an issue? OK, so it looks like (other than Pause/Break), the only remaining issues are that some Japanese keyboards have tricky behaviour to deal with (some keys act as a toggle at the hardware level). I still prefer the Raw Input API as the code is a lot cleaner and simpler than DirectInput and doesn’t create a second thread to process messages.

Why is Pause/Break an issue?

]]>
By: nicolas mercier/2011/04/25/input-for-modern-pc-games/#comment-3241 nicolas mercier Tue, 26 Apr 2011 13:40:01 +0000 Allan - Thanks - that makes sense. Most of my Win32 API work has been in DirectX land where structures are explicitly versioned rather than using the size of the struct to determine which one it is (which seems an awfully flaky system to me!). I guess this issue is what COM was meant to solve. Nicolas - Does that still apply with alternative keyboard layouts? AZERTY, etc? Allan – Thanks – that makes sense. Most of my Win32 API work has been in DirectX land where structures are explicitly versioned rather than using the size of the struct to determine which one it is (which seems an awfully flaky system to me!). I guess this issue is what COM was meant to solve.

Nicolas – Does that still apply with alternative keyboard layouts? AZERTY, etc?

]]>
By: nicolas mercier/2011/04/25/input-for-modern-pc-games/#comment-3237 nicolas mercier Tue, 26 Apr 2011 10:59:33 +0000 You usually have to pass in the size of a buffer whenever you pass a pointer to the Win32 API. Say you build and release your app today and the size of the structure that the API is going to read or write is 32 bytes according to the Windows 7 SDK. Then, in the future, someone runs your app on Windows 9 and by that time, that structure has been expanded and is now 40 bytes. Since the code that is doing the reading or writing ultimately resides in a system DLL, you're going to be running the Windows 9 version of the API against your old Windows 7 structure in memory. Windows 9 can use the size parameter that you pass in to avoid accessing memory past the end of the buffer and run that API call in a backward compatibility mode that will work with your old struct if necessary. You usually have to pass in the size of a buffer whenever you pass a pointer to the Win32 API. Say you build and release your app today and the size of the structure that the API is going to read or write is 32 bytes according to the Windows 7 SDK. Then, in the future, someone runs your app on Windows 9 and by that time, that structure has been expanded and is now 40 bytes. Since the code that is doing the reading or writing ultimately resides in a system DLL, you’re going to be running the Windows 9 version of the API against your old Windows 7 structure in memory. Windows 9 can use the size parameter that you pass in to avoid accessing memory past the end of the buffer and run that API call in a backward compatibility mode that will work with your old struct if necessary.

]]>
By: Keith Judge/2011/04/25/input-for-modern-pc-games/#comment-3215 Keith Judge Mon, 25 Apr 2011 15:23:09 +0000 ) states, you can’t get high precision mouse movement using the WM_MOUSEMOVE – you’re limited by screen resolution as the message won’t be generated until the mouse pointer has moved at least one (screen) pixel. With WM_INPUT (and DirectInput8), you’re only limited by the resolution of the mouse itself.

Also, using various values in the dwFlags member of RAWINPUTDEVICE, you can do things such as receiving input when your app is in the background (which I can see being useful for debugging), gain exclusive control of the mouse in windowed mode (as with DirectInput8) so that clicking won’t accidentally change input focus to another window, etc.

]]>
By: Andre Leiradella/2011/04/25/input-for-modern-pc-games/#comment-3213 Andre Leiradella Mon, 25 Apr 2011 15:09:39 +0000 Thank you for raising the localisation issues, not all keyboard layouts are QWERTY, and I had to remap the WASD keys to ZQSD (AZERTY layout) countless times... Thank you for raising the localisation issues, not all keyboard layouts are QWERTY, and I had to remap the WASD keys to ZQSD (AZERTY layout) countless times…

]]>