RE: [GD-General] Key handling revisited

[Matt D. <ma...@co...>]

Hi,

Most keyboards rely on single key presses or multiple keys being pressed at
the same time (e.g. Ctrl-F).  However, on some keyboards (like the German
ones) there are multiple key presses that are not done at the same time.  So
if you're allowing entering of text, be wary of that.

The best way of dealing with it is to treat as you would, say, your
renderer.  Figure out the use cases and design a high-level interface to
keyboard input.  Provide drivers under that layer which specialise in PC and
Macs and so forth.

For Galleon, we provide three mappings.

First, we map 'physical' buttons to 'virtual' buttons.  These removes the
platform dependency.  The virtual buttons are the keys used on our imaginary
keyboard.  Next we map 'virtual' to 'command' buttons.  This is called the
user map and is what the player creates by redefining the controls.
Finally, we map those keys to commands via a one-to-many mapping.  The game
reacts to the commands.

But the important thing to point out is that most of our input code is
platform independent except the code that provides the 'physical' button
information.

If you require text input, such a system would not be efficient.  Provide a
load of accessor functions, such as GetChar(), GetWideChar(),
IsControlPressed(), IsShiftPressed(), IsKeyUp(), IsKeyDown().  These
functions could be part of a class called CKeyboardEvent (or whatever) whose
sole purpose is to hold information of a single (or multiple in the case of
German keyboards) key press.  Provide CKeyboardDevice to provide the
platform dependecies and CKeyboardManager to use that and spit out
CKeyboardEvent classes.


Take care and good luck,



Matt Davies
Programmer, Confounding Factor
ma...@co...
www.confounding-factor.com



> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Brian Sharon
> Sent: 11 February 2002 16:08
> To: Tom Forsyth; Jamie Fowlston;
> gam...@li...
> Subject: RE: [GD-General] Key handling revisited
>
>
> > -----Original Message-----
> > From: Tom Forsyth [mailto:to...@mu...]
> > Sent: Monday, February 11, 2002 3:08 AM
> > To: Jamie Fowlston; gam...@li...
> > Subject: RE: [GD-General] Key handling revisited
> >
> > I think there are two separate issues, which Brian sort-of talked
> about.
> >
> > -Text input. Need to handle international chars,
> shift-alt-meta-squiggle
> > wierdness and all that. As much as possible, try to get the OS to do
> all
> > the
> > hard work. Usually queue-driven, so you won't miss keypresses. I don't
> > know
> > anything about macs, but on Windows you just use the WM_CHAR messages.
> > They
> > will tell you what is printed on top of the key that the user pressed,
> and
> > handle virtual keyboards and macros and so on. Probably exposed as a
> > stream
> > of ASCII-like things, except probably 16-bits wide. Could possibly use
> > UNICODE?
>
> Ahh, memories.
>
> Just remember that "there is not necessarily a one-to-one correspondence
> between keys pressed and character messages generated", as the
> documentation for WM_CHAR points out.  It may take a number of key downs
> to make that shift-alt-meta-squiggle (Meta?  this better not turn into
> another damn Emacs thread!).  Also look into WM_IME_CHAR if you want to
> handle double-byte characters in a non-Unicode window.  Otherwise, you
> can get two WM_CHAR messages for a single double-byte character.
>
> And of course, you'll get different actual values in your events
> depending on whether you're a Unicode window or not.  And Unicode
> windows aren't supported directly on Win9x.  Ugh.  Java, anyone? :)
>
> Macs - under the Classic event manager - deal with 8-bit keys and send
> the scan code along with the translated char.  I don't know how this has
> changed under Cocoa or Carbon.  It would be like a WM_CHARDOWN/WM_CHARUP
> combo if such a thing existed.  It's also 8-bit only so if you want to
> do Unicode translation you have to buffer up data until you get a valid
> conversion result into the current system script - at least, I'm pretty
> sure we handled it.
>
> So our x-plat layer used those events above and followed this model:
>
> * send keydown/keyup messages with our own virtual key constants, for
> dealing with gameplay presses - sending kLeftArrowKey, etc.
> * send Unicode char messages when x number of key presses generated a
> valid char, according to the OS
>
> But it would probably be better to poll for the first class of events
> and only send the second as actual events, which is the approach Tom
> outlines.  Either one is possible.
>
> So happy to not be dealing with this anymore,
>
> --brian
>
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU7