Sign in to follow this  
ArchangelMorph

Reading Input for Hi-Scores..

Recommended Posts

In my game I have a Hi-score table and I need to know what's the best way to read in user inputted characters to a string which I will be using in my hi-scores class.. A) I was thinking of reading each key pressed on the keyboard (using my DirectInput handler class..), checking to make sure its a valid character, adding it to the hiscore name string and displaying the current string to the screen.. B) Then obviously once "enter" has been pressed I would store the string into a hi-score object, put the object into my hi-scores array and sort them for display later.. I was wondering though if the steps taken in A) could be done quicker using maybe std::cin or something like that since it would save time writing the lengthy code unnecessarily..?

Share this post


Link to post
Share on other sites
Don't try to use DirectInput for text, as you'd have to write all the foreign keyboard handling yourself (and for some countries, that's incredibly complex with different keyboard modes and multiple key presses per character). Plus there's stuff like key repeat and delay and whathaveyou.

The easiest way is to process the Windows WM_CHAR message, which just gives you the characters that the user has typed, and hides you from a lot of the not-so-obvious complexities of text input.

Share this post


Link to post
Share on other sites
Quote:
I was thinking of reading each key pressed on the keyboard (using my DirectInput handler class..),


Don't! Doing text input properly is a lot more complicated than you might first think.

- DirectInput is for when you want to treat the keyboard like a 108+ button joypad not for text input. What it returns are raw scan codes, names such as DIK_Y only correspond to the standard USA keyboard layout - displaying a letter 'Y' when you see 'DIK_Y' got pressed is wrong on a German keyboard for example where the 'Z' key returns DIK_Y. Even UK keyboards don't match the USA layout fully (shift-3 is # on a US layout). Now there are ways to convert DirectInput/raw scan codes into ASCII characters, but there are other things to consider:

- DirectInput (and any other raw code API) tells you which keys were held down - but they don't tell you the relationship between the keys. e.g. "caps lock is on but the user held shift when the pressed the key so give them lower case instead of upper"; e.g. on some keyboards for languages that have marks such as umlauts above the letter, you press and release the key for the mark, then you press the letter you want the mark to appear above (along with shift, caps-lock, etc). You can write a ton of code to handle all those if you want too.

- People type at different speeds, hold keys down for different lengths of time, so people do customise things like the keyboard repeat/delay settings. Once again you can do all that yourself if you want (there are APIs to query the delay a user has configured).

- People in countries such as China & Japan use keyboards, but with so many characters possible in their languages, they also use a piece of software called an Input Method Editor (IME). DirectInput reads the keyboard codes not the IME. The IME under Windows has APIs you can use to query it.

- Some users have disabilities and so use accessibility options such as speech recognition and special layout keyboards that often require custom drivers - and yup, you probably won't get nice DIK_ codes from them either.

- People working in foreign countries often have to use keyboards they aren't used to so it's common to load a keyboard map for a layout they /are/ used to (e.g. I did some work in Denmark but installed the EN-GB keyboard layout). You can query layouts too.



In short, there's a lot you need to take into account if you want to support text input using raw scan-codes - and a fair bit of work too (I made the mistake of going down that route in the past - I wouldn't again).

So how should you do it? Windows text input does all of the above stuff and more - and is very simple to use:

- unacquire any exclusive hold you have over the keyboard in DInput

- in the window message handler (window procedure) for your main focus window (the HWND you passed to DirectInput), you should handle WM_CHAR messages - those come through after all the above nasty locale/preference/accessibility stuff has been done for you (and in the way the user configured).

- if you handle the message return 0 (IIRC) from your window procedure otherwise pass it on to DefWindowProc().

- when you're back into game, re-acquire etc



[edit: heh, beaten to it --- the above may still be handy if you're ever looking for justification for not using DirectInput for keyboard messages [smile]]

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this