AZERTY keyboard & scancodes issue
BlitzPlus Forums/BlitzPlus Programming/AZERTY keyboard & scancodes issue
| ||
| Hello there, in my game (in blitz showcase) I have a number of keyboard commands. Although it is possible to use the mouse as well, as of the most recent update, one of the users of the game has commented that if they press 'M' (to select the "male" character) on an AZERTY keyboard (I don't really know what that is though) then it does not register the keypress. Instead they have to press the key that on their keyboard is in the same place as the 'M' on a QWERTY keyboard. Is there a way I can get around this? Will using getkey() instead of keyhit(..) solve this issue? Thanks, Matt |
| ||
| AZERTY-Keyboards are used in France and Belgium. As GetKey and Keyhit both use the Scancode, changing them wouldn't change anything. I don't know if there's a way to detect what kind of keyboard is plugged in, but you could in the game-menu create an option where the user can decide whether he uses a 'QWERTZ','QWERTY' or 'AZERTY' Keyboard. |
| ||
| ... or even something to make completely custom keyboard layouts and no there isnt any way as b+ cant do anything related to drivers |
| ||
| Actually GetKey() returns the ASCII code, so maybe it would make a difference, as the keyboard shouldn't affect this I would have thought? |
| ||
| @Matty: Scancodes are "letter on key independent", they are only dependent on the position of the key on the keyboard. The nice thing about that is that you can offer a board schema with the keys it uses and it will work on all layouts even non US ones (unlike GetKey) and it will always remain as optimal US devs tend to forget such stuff heavily, thats why they often seem to use A-Y for input stuff, yet on many languages aside theirs Y is not even remotely next to A nor even reachable with the same hand and I really hate games that go the GetKey way without offering configurability. Please don't do their error as well |
| ||
| Hi Dreamora, I understand your point, and agree with it - for most cases. In this case it was a simple selection screen between M-ale and F-emale, and the M key was in a different place, and was not recognised with the scancode, so thought I could change it to a getkey() stroke for that instead. In such a case the position on the keyboard in terms for ergonomic purposes would not be so critical. However a better solution again would have been not only to use GetKey() but to show M-ale and F-emale in the user's respective native language... |
   |