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
>