Boring Look@Keyboard/Mouse Button Input

[Baker]

Another boring thread ...

Keyboard input works in this manner on Windows:

1. Designated message handler receives WM_KEYUP, WM_KEYDOWN, WM_SYSKEYUP, WM_SYSKEYDOWN. The first 7 bits of the lparam for the message handler contains the virtual key code for the physical key pressed on the keyboard (i.e. pressing 8 in the top row isn't the same physical key as pressing 8 on the keypad, the right shift key isn't the same as left shift key, etc.) and the Windows function can be used to obtain the ASCII (0-255 keycode) which in the Windows implementation appears to be able to support: English, French, German, Italian, Portuguese, Danish, Dutch, Norwegian, Icelandic and Spanish (according to Wikipedia).

In something like Quake where you want to be able to deal with continuous press states, versus say key repeats and the timing issues this would present (example the +turnleft key where this would work differently based on control panel settings, had it been implemented another way), both the virtual key and the what that key represents are 2 separate pieces of information. Quake overcomes this with a fixed key map table, the disadvantage of which this that the hardcoded keys are only correct for, say, an English keyboard. [Quake 3 and, for example, DarkPlaces use the ToAscii method to correctly map the keys for non-English keyboards].

In Quake, there are 3 situations that should be nullified: ALT-SPACE if the Window is full-screen (arguably windowed mode too) as ALT-Space triggers the start menu (WM_SYSCHAR, returning a zero takes care of that.) StickyKeys, ToggleKeys, Filter keys are undesirable and those can be disabled by API (they must be re-enabled on exit). And the "Windows" key and "Context menu key" which can be nullified via SetWindowsHookEx and setting a function to handle it which returns 1 for those keys (VK_LWIN - left Windows key, VK_RWIN - right Windows key, VK_APPS --- context menu).

2. The console. In Quake, certain keys are often coded to behave in a specific way when the console is displayed. The arrow keys, for instance, always move the cursor. Some engines have the numeric keyboard always produce numbers in the console, ignoring the numlock key state.

3. In Quake, the keys that mapped to Quake button functions such as "+attack" or "+jump" also keep track of up to 2 keys that may have been pressed to trigger that function to ensure that a continuous "attack" or "jump" can be maintained even if two separate were pressed to do the same thing.

4. Overcoming timing: It is possible for a key to be pressed and released quickly enough both occur during the same frame (i.e. what you are getting 30 FPS on some giant map in a wide open area). In that event, Quake does something interesting: a button pressed and released within a frame receives a fraction of 0.25, a button pressed or released during a frame gets a fraction of 0.5 and a continuously held button receives a fraction of 1.0 --- these are used in combination with the amount of time for the frame (i.e. 100 frames per second = 1/100 of a second) for angle manipulation like pressing an arrow key to turn left or right or some other key to look up.

[andrewj]

[Baker]

[Spike]

you'll need to remove all associations between scan code and unicode char values, and to query the system for which unicode char should be generated from the sequence of scan codes given.

Its generally assumed that its always possible to type in latin chars, and that there'll always be a shift, alt, and ctrl key, but there are other modifiers also.
For example, there are 'accent' chars on certain keyboards, which do not work as ctrl+v does, but function sequentially. Press 'grave' and then 'a' and you get an 'a-with-grave-accent' unicode value.
However, you do still have to be able to cope with certain buttons, like 'uparrow' which has no unicode character value associated with it.
Imho, the only sane choice is to recognise control characters (ctrl, escape, uparrow, etc) by scancode, and only if their unicode value is unspecified, and for any printable stuff, use only the unicode value.
Which is all well and good until you come to binds. Which will likely need to use scan codes (with your own modifier key support).
Why not use unicode chars for binds? Because people don't expect shift+w to be a different bind from w, nor altgr+e to be 'whatever é is bound to' instead of 'whatever altgr is bound to, and whatever e is bound to'. Trust me. Users complain if their other buttons do weird things just because they're trying to strafe.
The other reason, of course, is that not all systems provide unicode char values for key releases. You would need to use scan codes for this anyway (tracking which scancode provides which unicode bind, and releasing that unicode binding when the scancode that matches it is released, though even with that you still have the problem that ctrl+r will still be 'down' even when ctrl is released, but perhaps that's what you want).

I cannot possibly begin to explain how a chinese keyboard works, as I have never had reason to use one.


However, input is only a third of the problem.
The other thirds are:
printing unicode chars, which font to use, and how that font is activated. Its pointless to accept weird accents and stuff if noone can actually see them once entered.
networking and compatibility - utf8 perhaps? that'll break with quake's 'highchars'. Special flags to say what text decoding algo to use perhaps? Lets hope your servers don't mangle it when handling 'say' commands. You'll still need to bounce it off servers (and probably support it in the mod too). Either way, you'll likely need to separate internal representation from network representation, at least if network/mod compat is desired.

[Baker]

[taniwha]

Heh, I went the other way with key support: instead of dropping things like scroll-lock etc, I added things like hankaku/zenkaku, muhenkan, ... (I have a Japanese keyboard and hankaku/zenkaku is where ~/` is on US keyboards. Most inconvenient ). Actually, my current kb is a Japanese MS Natural Ergonomic Keyboard 4000. I made it so that if X Windows responds to the key, QF knows about it. Unfortunatly, the five favorites keys and the zoom thingy in the middle don't work (linux kernel issue). Same with "Spell Check".

[Baker]

[Spike]

keyboards tend to have some weird criscrossy matrix of wires connecting all across the keyboard. it generally figures out which button was pressed based upon resistance or something. This means it can't cope with you pressing multiple keys at once.

From memory, the USB keyboard protocol accepts up to 8 modifiers and 6? keys held at once. Its not possible for the keyboard to report that more keys than that are held, even if there's a separate thingie for each button.
Keyboards also have weird mapping inside them to cope with the somewhat random reordering of keys on modern keyboards. Eg for keys that were added after the original keyboards - they're all vaugely compatible with some original spec.
Standard PS2 controllers also have a tendancy to remap keys in hardware, for dos compatibility.
'Function' keys on laptop keyboards are part of the keyboard, rather than the operating system. They result in different scan codes, which may or may not be handled by the bios.
With all the remapping all over the place, its somewhat unsurprising that you are limited to 3 keys.

On windows, you can use ToUnicode to get the unicode char value from pressed keys. Like I say though, you'll still need to cope with keys which are non-printable. And of course cope with weird keymaps where '1' is actually '&', while 'shift+1' is required to actually get a '1' (eg: french) - the issue is how you go from the string name of the key to the scancode. I've yet to see docs for that with android... Windows at least has a 'VkKeyScan' function if you don't mind being awkward-to-implement system dependancies.

[Baker]

Not sure I care, but this supposedly disables the capslock key:

http://www.codeguru.com/cpp/misc/misc/k ... k-keys.htm

My only interest in the above to allow normal usage of the capslock key as a bind in-game without any other effects.

[Spike]

presumably you only want to disable capslock for binds. either way it won't affect scan codes, so if that's what your binds are based upon then capslock won't affect anything anyway.
if your binds are based upon the unicode char value, then you'll have major issues with shift - capslock isn't special.

[Baker]

[Spike]

[Baker]

[Spike]

Con_Printf("0x%x 0x%x\n", wParam, HIWORD(lParam));

3 down -> 0x33 0x4
3 up -> 0x33 0xc004

shift down -> 0x10 0x36
£ (aka: 3) down -> 0x33 0x4
£ (aka: 3) up -> 0x33 0xc004
shift up -> 0x10 0xc036

same with punctuation, so no real difference between virtual keys and the scan codes, other than the scan codes have an extra bit or two saying that it was released, and the actual values are different.

At the hardware level, the scancode is a somewhat sequentially increasing value, based upon really old keyboard layouts, thus escape is 1, and the number keys come next. Just sequentially allocated based upon the original keyboard layouts before f1 etc were added.
Windows virtual keys seem to be a slightly more ascii compatible mapping of the same scan codes, but only really make any sense for alphanumeric chars. use punctuation and its pointless.
Still, different hardware has different scancodes, so I suppose its useful as a way to work around that.

You can always switch your own keyboard layout to a european one to test it yourself. Beware that windows can switch keymaps automatically between different programs. shift+alt will generally cycle the current keymap, if you get stuck trying to find some key.