Jump to content


Photo

KBTester

extension

  • Please log in to reply
5 replies to this topic

#1 csanyk

csanyk

    GMC Member

  • GMC Member
  • 624 posts
  • Version:GM:Studio

Posted 03 May 2015 - 05:38 AM

KBTester is a utility/demo I made to help out with coding your keyboard_check routines. It is born out of frustration and necessity for handling certain inputs from a very fundamental input device for computer games, the standard keyboard, which are not supported out of the box.

 

If you program keyboard input in your games, you'll find that, for most keys on a computer's keyboard, you can use vk_constants and ord(letter)... but for some odd reason YYG didn't create a vk_constant for every key on the keyboard, and don't plan to.  Not only that, but there are certain keys that don't return the right value for ord() to work with keyboard_check.  

 

For example, say you want to check if the period key is pressed.  You might think that you can do keyboard_check(vk_period) but to your surprise, there is no vk_period constant defined in GML.  So, then it must be that you need to do keyboard_check(ord(".")) only... it doesn't work!  

 

That's because ord(".") returns a value of 46.  But for some reason, if you want keboard_check() to return true when the period key is pressed, you need to check for the value 190.  Why? Why are certain keys on the standard keyboard treated as second-class citizens? Because, sadly it's not in YYG's vision to improve keyboard support.  

 

To paraphrase a certain "Evil YoYo Games Employee" who commented on my suggestions for ways the current keyboard support badly needs to be improved:

<paraphrased>Why should we improve keyboard support when you can just research what codes map to your keyboard keys, make an extension that has a few constants in it, and then hope that these will work with all keyboards and all target platforms?  Just code it once and then put it up on the Marketplace.  Now that the marketplace exists to provide stopgap coverage of GM:S shortcomings, we don't have to pay our own programmers to fix those holes anymore.</paraphrase>

 

 

So, I guess we're supposed to figure out the numbers and then code some constants for the missing vk_constants, and use those.  This, despite the helpfile recommending against using hardcoded numeric values in keyboard_check because you never know if it'll work on the target platform if it's not Windows/Mac/Ubuntu:

 

NOTE: These functions are designed for Windows/Mac/Ubuntu desktop platforms only. You may find some of the in-built variables and constants aren't valid on other platforms and many of the functions won't work on mobiles.  
 
Now, each key is normally defined by a number, called the ascii code, and you can directly input this number into these functions and they will work fine... But, as it's a bit difficult to remember so many numbers and the relationship that they have with your keyboard, GameMaker: Studio has a series of constants for the most used keyboard special keys and a special function ord() to return the number from ordinary typed characters (either letters or numbers).

 

 

The implication is that, YYG seem to be saying, "Despite the promise of GM:S as a development environment that supports multiple target platforms, we didn't see the need to ensure that your code will run on all target platforms we support, or after looking into it decided it was too hard for us to deal with, so we're passing it along to you to figure out for yourself.  So just be aware that these may or may not work on all platforms, and that's all the info we're going to give you about that.  You're on your own to figure out how to solve keyboard input from any platforms that don't work with our keyboard input functions."

 

Well, for whatever reason, YYG doesn't provide FULL keyboard coverage between ord() and vk_constants, and it's not in their vision to address this shortcoming, so I guess you're going to have to go out and find some reference that will tell you what numbers represent what key, and then hope they still work.  

 

Or, you can use KBTester, press a key, and get the answer without having to hunt the info down and hope it's correct.  If you're having trouble getting keyboard_check to work, and need to verify that the magic number you're using is indeed the right one, you can run KBTester.  Press a key and KBTester will tell you the value that GameMaker sees.  

 

In time, I'll be releasing additional extensions that take as much of the pain out of the current keyboard support model as possible, providing as many of the improvements that I had suggested as I am capable of programming.  Because half the fun of developing video games is dealing with odd keyboard layouts, not glamorous high level stuff like level design and play mechanics.


Edited by csanyk, 03 May 2015 - 05:59 AM.

  • 0

#2 Lonewolff

Lonewolff

    Permanent Resident

  • GMC Member
  • 3517 posts
  • Version:GM:Studio

Posted 03 May 2015 - 05:45 AM

The problem is caused more by regional settings than by YYG's reluctance to have the user have access to all keys.

 

You'll find that the apostrophe key, for example, returns different values for different regions. So, knowing the 'magic' number is generally no good to you.


  • 0

#3 csanyk

csanyk

    GMC Member

  • GMC Member
  • 624 posts
  • Version:GM:Studio

Posted 03 May 2015 - 05:53 AM

The problem is caused more by regional settings than by YYG's reluctance to have the user have access to all keys.

 

You'll find that the apostrophe key, for example, returns different values for different regions. So, knowing the 'magic' number is generally no good to you.

 

Exactly!  That's why I suggested YYG to abstract the regionality of the keyboard away from the user, so we can do things like vk_apostrophe and have it work on any keyboard.  Too much work for them, I guess.  It doesn't seem like something that should be hard to figure out how to get the keyboard map from the hardware and translate vk_constants to the proper key regardless of the underlying ascii value associated with it on an arbitrary keyboard layout.  Creating a vk_constant of my own in macros will probably only work for my region's keyboard, and won't be a universal fix.


  • 0

#4 kburkhart84

kburkhart84

    Firehammer Games

  • GMC Member
  • 2026 posts
  • Version:GM:Studio

Posted 04 May 2015 - 03:31 AM

Not to bag on the product, but just as a comment, this is why I never hard code things like this, rather let the user choose game inputs by actually hitting the keys.  It won't always be correct in the settings menu, but the button they hit is the button that will work, regardless of which region they are in, etc... as long as it is part of the 256 keys in the array.


  • 1

My KBInput system is now on the marketplace here.  It wraps up nice and tight GMStudio's input system into a few function calls making a user configurable input system that works the same regardless of what inputs the player has chosen including keyboard, mouse buttons, and gamepad/joysticks using DInput/XInput.  The support forum topic for it is here.


#5 csanyk

csanyk

    GMC Member

  • GMC Member
  • 624 posts
  • Version:GM:Studio

Posted 04 May 2015 - 02:41 PM

Not to bag on the product, but just as a comment, this is why I never hard code things like this, rather let the user choose game inputs by actually hitting the keys.  It won't always be correct in the settings menu, but the button they hit is the button that will work, regardless of which region they are in, etc... as long as it is part of the 256 keys in the array.

 

While that's a fine recommendation to make, it doesn't do much to address the actual shortcoming in the current keyboard support.  Setting up a configuration screen and allowing the player to change the controls is a great feature, but it requires considerable work to implement such a system, and is not something that a novice GM:S user is necessarily ready for.  I don't think that every project necessarily needs this -- certainly a professional release should, but sometimes you just want to make a quick project and don't have time to implement all the fancy features like user-configurable input, but you do want to set up hardcoded controls that use specific keys which currently aren't easy to access through vk_constants or ord().


  • 0

#6 kburkhart84

kburkhart84

    Firehammer Games

  • GMC Member
  • 2026 posts
  • Version:GM:Studio

Posted 04 May 2015 - 04:45 PM

Don't get me wrong, I understand completely what you are doing.  I have some pre-canned code I'm using for custom player inputs, but a beginner could possibly have trouble using even something like this pre-canned.  I think the problem that Yoyo might have trying to make this work is just how many different keyboards and regional settings there are.  It would be great to have this working right, but as I understand it, even large studios have problems getting things working perfect through all these international regional issues.


  • 0

My KBInput system is now on the marketplace here.  It wraps up nice and tight GMStudio's input system into a few function calls making a user configurable input system that works the same regardless of what inputs the player has chosen including keyboard, mouse buttons, and gamepad/joysticks using DInput/XInput.  The support forum topic for it is here.






Also tagged with one or more of these keywords: extension