🔒 Locked

DirectInput

Started by Hiewk Apr 12, 2005 at 10:37 AM 3 replies 500+ views

Original Post

Apr 12, 2005 at 10:37 AM

Hi I'm currently programming a console for my 3d engine, and i've came up with an input problem. The engine is currently using directinput to check for key presses, and although it's capable to tell if its the first time a key is pressed or if its a key wich was already down in last frame, and to convert some keyboard constants to chars, it's just not enough. There are many combinations of keys wich should return a specific char, and also i cant copy the repeating system we have on windows (when we let a key down, after x time it starts repeating the char) without slowing it down. So could someone point me a solution? Should i just use win32 api for this? Is there any function or technique wich could sort the problem out? Thanks!

neneboricua19

Apr 12, 2005 at 11:29 AM

For console input, you should really just use Win32. DirectInput wasn't made for text entry. It was made for very fast game input. Although it is possible to use DirectInput for text entry, its not easy and the job is just as nicely done using Win32 anyway.

neneboricua

jollyjeffers

Apr 12, 2005 at 11:32 AM

I use the buffered input (effectively event based) DInput model and it works pretty well.

I also have a "double layer" whereby the underlying input engine translates the raw data into messages along the lines of WM_KEYDOWN, WM_KEYUP style windows messages. The main GUI controls (one of which is a text box) registers a timer (set for 100ms intervals), and it maintains a list of which keys are pressed down - if the same combination was pressed down in the last iteration we know it's been held down and thus starts repeating it...

For the key combinations (such as a "6" and a "shift" not registering as a "^" symbol) you want to decode the input buffer completely before despatching/translating the actual key events. E.g. run through all of the events, storing a 256-element array of booleans (iirc there are 256 keycodes), including any previous buffer passes (so as to maintain your own internal state of the keyboard). Once you have this, you can despatch messages (like my original paragraph) but also include a shift/alt/ctrl parameter. You could decode a "shift" + "6" = "^" directly in this layer, but thats a bit restrictive for non-text input based keystrokes (i.e. doesn't work so well for accelerators).

In the OnKeyPress( int key, bool shift, bool ctrl, bool alt) type function, you can decode the key as a char:

if( shift || ctrl || alt ) {    //You might need to process the key as being an accelerator/combination}else {    //no modifier keys pressed, thus a "6" is actually a "6" and not a "^"}

Once you've decoded it as a char, you can append it to your console input/output as you want.

There is a little more to it than that - handling delete/backspace/tab for example, but it's essentially all just logic. Sadly, I don't know of any built-in out-of-the-box DirectInput functions that'll do all this for you...

hth
Jack

jollyjeffers

Apr 12, 2005 at 11:33 AM

Quote:
Original post by neneboricua19
For console input, you should really just use Win32. DirectInput wasn't made for text entry. It was made for very fast game input. Although it is possible to use DirectInput for text entry, its not easy and the job is just as nicely done using Win32 anyway.

neneboricua

[lol] Took too long writing an explanation of my system. That in itself could be proof as to why it's (probably) easier to use Win32 instead of DInput [rolleyes]

Jack

Topic Locked