FW: [GD-General] Key handling revisited
Brought to you by:
vexxed72
Menu
▾
▴
FW: [GD-General] Key handling revisited
|
From: Tom F. <to...@mu...> - 2002-02-12 10:55:27
|
Another victim of the list settings... Tom Forsyth - Muckyfoot bloke. -----Original Message----- From: Ignacio Casta=F1o [mailto:cas...@ya...] Sent: 11 February 2002 21:48 To: Tom Forsyth Subject: Re: [GD-General] Key handling revisited Or you can just use MapVirtualKeyEx followed by ToAsciiEx to map direct input virtual keys, to ascii characters. That works well with special characters (=E1=E9=F4=FC etc.), and also with key combinations if you = get the keyboard state with GetKeyboardState, and use it with ToAsciiEx. The only problem I've found with that is that with low framerates you = can loose a shift or alt key because dinput is buffered and = GetKeyboardState is just polling, but that can be solved using your own buffer for key = states. Ignacio Casta=F1o ca...@as... Tom Forsyth wrote: > 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=3D86 > > > -----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=3D557 > > > > > > _______________________________________________ > > Gamedevlists-general mailing list > > Gam...@li... > > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=3D557 > > > > _______________________________________________ > Gamedevlists-general mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D557 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
