[Ohrrpgce] SVN: jay/3923 gfx_directx: Fixed shift key problem, for real. :\ Adjusted keyboard inp

[Jay Tennant]

> From: Ralph Versteegen <teeemcee at gmail.com>
> Sent: Friday, October 22, 2010 10:54 PM
> 
> On 23 October 2010 16:09, James Paige <Bob at hamsterrepublic.com> wrote:
> > On Fri, Oct 22, 2010 at 07:58:01PM -0700, subversion at HamsterRepublic.com wrote:
> >> jay
> >> 2010-10-22 19:58:01 -0700 (Fri, 22 Oct 2010)
> >> 407
> >> gfx_directx: Fixed shift key problem, for real. :\ Adjusted keyboard input to be polled through GetKeyboardState() instead of window messages.
> >>
> >> The caps lock, num lock, and scroll lock must not be assigned correctly. The test app gfx_directx_test1.cpp tests positively that they return correctly, but the engine must be expecting different bits to be set?
> >>
> >> What bits does the engine expect for a toggle key?
> >
> > The engine has absolutely no concept of a toggle key. In the QB days, it
> > expected toggle keys to behave exactly like regular keys. The gfx_fb
> > backend emulated this.
> >
> > The gfx_sdl does it the same way except for the CAPSCLOCK key. If I
> > understand correctly, SDL
> > itself treats capslock as if it is always being held down when it is in
> > the ON state.
> 
> This behaviour can be turned off in SDL 1.2.14 (and we do if we can),
> but is always-on in SDL 1.2.13 or earlier.
> 
> > I am not sure what is best for the gfx_directx backend to do with toggle
> > keys.
> >
> > I know we definitely need to fix any places where capslock us used for
> > silly things. (Is the sprite editor color-picker the only remaining
> > example of that? I can't remember for sure.)
> 
> You mean scrolling?
> 
> I don't know of any other place that we ever used capslock - not even
> for capitalising!

I've tested the Caps Lock key in the sprite editor, and it works.
It doesn't work for text editing, which would agree with your
statement. Perhaps having a single function to translate keypresses
into characters, based on whether shift, alt, ctrl, capslock, etc. are
pressed?

I'd be happy to work out this function, though I won't get to it until
tomorrow night.

Since it'd be translating keys to characters, it should probably convert
to unicode. TMC has been talking about converting to unicode to support
dead characters like the umlaut o. On the other hand, this requires
the engine be able to draw those characters.

Since the keyboard input is through the backend, it may also be
appropriate that the backend perform this translation.

To start, perhaps a keypress-to-ascii character translation within
the engine. I'll get on that tomorrow night.

> On the other hand, we have some other toggle keys. Numlock/pause
> in-battle is problematic; we need to add an alternative.




_______________________________________________________
Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting
              http://www.doteasy.com