gamedevlists-general

RE: [GD-General] Key handling revisited

[Tom F. <to...@mu...>]

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?

-Game control input. You just want the keyboard to be returned as a big
keypad with 100+ keys, and tell you which keys are pressed at any one time.
This is what DirectInput exposes. Usually polled, not queue-driven, it's
just a big array of key states (up/down).


The only crossover between the two is when the user is defining their keys.
Then you want to find what is printed on the top of the key that the
"gamepad" has pressed down. Fortunately you can assume that when they are
being defined, the user will be pressing exactly one key at a time, so just
watch both systems to see which WM_CHAR-like message corresponds to which
keypad keydown.


For Windows+DirectX, you're pretty sorted - WM_CHAR for the first,
DirectInput for the second. I don't know much about other platforms.


Tom Forsyth - Muckyfoot bloke.

What's he up to now (and can I have a go)?
http://www.eidosinteractive.com/downloads/search.html?gmid=86

> -----Original Message-----
> From: Jamie Fowlston [mailto:ja...@qu...]
> Sent: 11 February 2002 10:36
> To: gam...@li...
> Subject: RE: [GD-General] Key handling revisited
> 
> 
> I'm also interested in a related issue: if anyone has a 
> sensible input model
> that can work across computers and consoles, i'd love to hear 
> it :) at the
> moment the plan is to reimplement the control interface on 
> each platform
> (it'll need tweaking for each platform anyway), but i don't 
> want to have to
> do more work than is necessary on a problem that _surely_ 
> must have been
> solved? :)
> 
> Jamie
> 
> 
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Brian Hook
> Sent: 10 February 2002 02:39
> To: gam...@li...
> Subject: [GD-General] Key handling revisited
> 
> 
> After thinking about my key handling situation for a day, I 
> think I finally
> stumbled upon the obvious solution.
> 
> Fundamentally I wasn't differentiating between ASCII 
> characters and raw key
> codes, so I ended up just having a jumble of logic both on 
> the key reading
> side (my platform driver) and on the application side.  My 
> HEvent structure
> only had a keyCode member, which mapped to my system virtual 
> key constants
> (directly taken from the VK_ constants in WINUSER.H so that 
> there was a
> one-to-one mapping).
> 
> To simplify my life, I just added another field, evChar, 
> which is the ASCII
> representation of the virtual key code.  So I can 
> differentiate between top
> row "0", keypad "0", or just read an ASCII "0" depending on 
> the needs of
> the calling routine.
> 
> Yeah, kinda duh, but for some reason I was just focused on 
> having a single
> key code and doing the appropriate thing with it at all times.
> 
> Of course, this doesn't address the issue of international 
> keyboards.  I
> have no idea what to do about that, other than just hope and 
> pray it's not
> a problem.  And if it is, I guess I'll deal with it then.
> 
> Brian
> 
> 
> 
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 
> 
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 

RE: [GD-General] Key handling revisited

[Brian S. <bs...@mi...>]

> -----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
>=20
> I think there are two separate issues, which Brian sort-of talked
about.
>=20
> -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,
=20
--brian

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

RE: [GD-General] Key handling revisited

[Jamie F. <ja...@qu...>]

that's exactly the system i've set up. what i'm currently not too happy with
is the state / event split. obviously you can generate events from states
and vice versa, just seems a bit yucky....

presumably the processing of the physical button also has to be platform
dependent, as the buttons vary.

Not had to handle text input yet, may not have to (fingers crossed :)

Jamie


-----Original Message-----
From: Matt Davies [mailto:ma...@co...]
Sent: 12 February 2002 09:57
To: Brian Sharon; Tom Forsyth; Jamie Fowlston;
gam...@li...
Subject: RE: [GD-General] Key handling revisited


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

RE: [GD-General] Key handling revisited

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

Yes, that's right.  The first mapping is set up, per platform, in our editor
so that we can handle input in a platform independent way. The so-called
'virtual' buttons cover all keyboards in a generic way.

As a summary:

Physical buttons  (platform dependent)
   |
   |   (Physical mapping)
   V
Virtual buttons   (platform independent)
   |
   |   (User mapping)
   V
Command buttons	(platform independent)
   |
   |   (Command mapping)
   V
Commands          (platform independent)


The user mapping is maintained by a 'define controls' screen but it is
intially set up as button 0 maps to 0, button 1 maps to 1, button 2 maps to
2, etc.  This means that the virtual buttons and the command buttons are
basically the same at default.

The command mapping has a 1 to many relationship.  So we can set up a
mapping that links our attack button to punch and kick commands.  If we
wanted to, it will be easy to have them on seperate buttons by changing the
mapping and not by changing the code.  This flexibility is useful.


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


--- Excerpt from Jamie Fowlston

> presumably the processing of the physical button also has to be platform
> dependent, as the buttons vary.

RE: [GD-General] Key handling revisited

[Grills, J. <jg...@so...>]

We have a totally separate system for text input and game control input as
Tom suggests.  The text input system is reasonably straight forward, but the
game control system is pretty interesting, so it's all I'll describe here.

We have a class in the engine called InputMap which converts raw user input
into a series of game events, which is all the game ever sees.  The raw user
input is taken as a stream of events, where an event contains the device id
and the change that happened to it.  All we need to do in code is read the
hardware and send the events to the InputMap.  Then, in data, we create a
new InputMap mapping from the hardware (keyboard keys, joystick buttons,
mouse buttons, or any and all of them) to the game event identifiers.  Each
game event has both a type (move forward, turn, shoot, etc) and a float
value.  We treat digital buttons (keys, many game pad buttons) different
from anything with variable input (joystick axis, pressure sensitive game
pad buttons, POV hats).  

Digital buttons can have several messages associated with them sent at
different times.  There's a message when the buttons is pressed, one when
it's still down (repeated), one when it is released, and one if the
application loses focus (used only by PC platforms).  If you want a button
to issue a single event, you likely only assign it a pressed message.  If
you want it to react whenever it is down, you could assign it the same
pressed and repeat message.  If you want something like a Decent plasma gun,
the press message could send a "start charging" message, the repeat message
could send a "continue charging" message, and the release could send a
"fire" message.  If the user task-switched while charging, the lost focus
message could be "abort firing".  Buttons can also have the same message but
different values associated with them.  Strafe left and strafe right can be
implemented with two buttons but one game message with different values
(-1.0 and 1.0).  You could also have walk, walk fast, and walk slow be three
buttons sending "walk" with different values. 

Some buttons can be designated as shifting keys.  Shifting keys add or
remove bits from a shift state bit mask.  The current shift state bit mask
determines which button map will be used for the messages.  One of the most
tricky problems to solve was what to do when a user presses a key, then
presses a shift key, then releases the key before releasing the shift key.
We decided to bind all the messages a key will ever send at the time that it
is pressed.  This seems to have the least amount of user surprise, and is
relatively simple to implement (just copy the data on press).

Joystick axis and POV hats are handled differently.  They always send down
their message per frame, but the value is taken from a mapping of the
position of the stick or the hat.  Pressure sensitive buttons could be
handled the same way.  Any change to the shifting state instantly changes
the messages that variable input device sends.

In your code that processes the game events, you may need to be careful to
make sure that users can't gain an advantage by mapping multiple keys to the
same event and have the sum of those events exceed some allowable game play
threshold.

Hope this helps,

Jeff Grills
Technical Director, Austin Studio
Sony Online Entertainment

-----Original Message-----
From: Jamie Fowlston [mailto:ja...@qu...]
Sent: Monday, February 11, 2002 5:18 AM
To: gam...@li...
Subject: RE: [GD-General] Key handling revisited


that's really my problem :) for any given system, there's an obvious
approach to use. just trying to unite the ps2 and pc principles is hard, let
alone going further afield than that. the pc is event driven, whereas the
ps2 is state driven. you can translate between the two, but it's a bit
whiffy.

jamie


-----Original Message-----
From: Tom Forsyth [mailto:to...@mu...]
Sent: 11 February 2002 11:08
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?

-Game control input. You just want the keyboard to be returned as a big
keypad with 100+ keys, and tell you which keys are pressed at any one time.
This is what DirectInput exposes. Usually polled, not queue-driven, it's
just a big array of key states (up/down).


The only crossover between the two is when the user is defining their keys.
Then you want to find what is printed on the top of the key that the
"gamepad" has pressed down. Fortunately you can assume that when they are
being defined, the user will be pressing exactly one key at a time, so just
watch both systems to see which WM_CHAR-like message corresponds to which
keypad keydown.


For Windows+DirectX, you're pretty sorted - WM_CHAR for the first,
DirectInput for the second. I don't know much about other platforms.


Tom Forsyth - Muckyfoot bloke.

What's he up to now (and can I have a go)?
http://www.eidosinteractive.com/downloads/search.html?gmid=86

> -----Original Message-----
> From: Jamie Fowlston [mailto:ja...@qu...]
> Sent: 11 February 2002 10:36
> To: gam...@li...
> Subject: RE: [GD-General] Key handling revisited
>
>
> I'm also interested in a related issue: if anyone has a
> sensible input model
> that can work across computers and consoles, i'd love to hear
> it :) at the
> moment the plan is to reimplement the control interface on
> each platform
> (it'll need tweaking for each platform anyway), but i don't
> want to have to
> do more work than is necessary on a problem that _surely_
> must have been
> solved? :)
>
> Jamie

RE: [GD-General] Key handling revisited

[Jamie F. <ja...@qu...>]

that's really my problem :) for any given system, there's an obvious
approach to use. just trying to unite the ps2 and pc principles is hard, let
alone going further afield than that. the pc is event driven, whereas the
ps2 is state driven. you can translate between the two, but it's a bit
whiffy.

jamie


-----Original Message-----
From: Tom Forsyth [mailto:to...@mu...]
Sent: 11 February 2002 11:08
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?

-Game control input. You just want the keyboard to be returned as a big
keypad with 100+ keys, and tell you which keys are pressed at any one time.
This is what DirectInput exposes. Usually polled, not queue-driven, it's
just a big array of key states (up/down).


The only crossover between the two is when the user is defining their keys.
Then you want to find what is printed on the top of the key that the
"gamepad" has pressed down. Fortunately you can assume that when they are
being defined, the user will be pressing exactly one key at a time, so just
watch both systems to see which WM_CHAR-like message corresponds to which
keypad keydown.


For Windows+DirectX, you're pretty sorted - WM_CHAR for the first,
DirectInput for the second. I don't know much about other platforms.


Tom Forsyth - Muckyfoot bloke.

What's he up to now (and can I have a go)?
http://www.eidosinteractive.com/downloads/search.html?gmid=86

> -----Original Message-----
> From: Jamie Fowlston [mailto:ja...@qu...]
> Sent: 11 February 2002 10:36
> To: gam...@li...
> Subject: RE: [GD-General] Key handling revisited
>
>
> I'm also interested in a related issue: if anyone has a
> sensible input model
> that can work across computers and consoles, i'd love to hear
> it :) at the
> moment the plan is to reimplement the control interface on
> each platform
> (it'll need tweaking for each platform anyway), but i don't
> want to have to
> do more work than is necessary on a problem that _surely_
> must have been
> solved? :)
>
> Jamie
>
>
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Brian Hook
> Sent: 10 February 2002 02:39
> To: gam...@li...
> Subject: [GD-General] Key handling revisited
>
>
> After thinking about my key handling situation for a day, I
> think I finally
> stumbled upon the obvious solution.
>
> Fundamentally I wasn't differentiating between ASCII
> characters and raw key
> codes, so I ended up just having a jumble of logic both on
> the key reading
> side (my platform driver) and on the application side.  My
> HEvent structure
> only had a keyCode member, which mapped to my system virtual
> key constants
> (directly taken from the VK_ constants in WINUSER.H so that
> there was a
> one-to-one mapping).
>
> To simplify my life, I just added another field, evChar,
> which is the ASCII
> representation of the virtual key code.  So I can
> differentiate between top
> row "0", keypad "0", or just read an ASCII "0" depending on
> the needs of
> the calling routine.
>
> Yeah, kinda duh, but for some reason I was just focused on
> having a single
> key code and doing the appropriate thing with it at all times.
>
> Of course, this doesn't address the issue of international
> keyboards.  I
> have no idea what to do about that, other than just hope and
> pray it's not
> a problem.  And if it is, I guess I'll deal with it then.
>
> Brian
>
>
>
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>
>
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>

Re: [GD-General] Key handling revisited

[Erwin de V. <er...@vo...>]

> The only crossover between the two is when the user is defining their
keys.
> Then you want to find what is printed on the top of the key that the
> "gamepad" has pressed down. Fortunately you can assume that when they are
> being defined, the user will be pressing exactly one key at a time, so
just
> watch both systems to see which WM_CHAR-like message corresponds to which
> keypad keydown.

You can also get the name of the button through Directinput. We used that in
our game for key defining (dont use it for text input!!), but we've seen
some really strange names on some systems. All caps, different naming styles
for the arrow keys, and more of that nonsens. Though i havent looked into it
deeply it appears to depend on a lot of things. Hope it helps.

Erwin