+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: QB64 Rising (https://qb64phoenix.com/forum/forumdisplay.php?fid=1)
+--- Forum: Code and Stuff (https://qb64phoenix.com/forum/forumdisplay.php?fid=3)
+---- Forum: Works in Progress (https://qb64phoenix.com/forum/forumdisplay.php?fid=9)
+---- Thread: Keyhit library update (/showthread.php?tid=1176)
Pages:
1
2
RE: Keyhit library update - SMcNeill - 02-10-2023
What you've got looks a whole lot like my keyhit library, except it's not quite as advanced. What you're tracking is a single button's up/down state, to see when it might be pressed, while the keyhit code here does that and applies key modifiers to it.
The difference in a nutshell?
You report Shift-A as two key presses -- "Shift" is down, "A" is down.
This library reports Shift-A as two modified key presses -- "Shift" is down (it doesn't modify), "A" might be down, or "a" might be down (depending on CapsLock state).
One thing for you to be careful of -- _DEVICES is glut bugged, just like the rest of the QB64 keyboard input commands. There are various keys and combos which *WILL NOT* register using _DEVICES. From memory, I *think* the ALT keys are two of the most obvious which _BUTTON doesn't read or recognize. It's this basic glut glitch which led to me creating this keyhit library for windows, as it relies on basic windows API commands to get our keyboard state for us, and bypasses glut completely.
Good news though! Matt is currently looking into our keyboard input routines and *thinks* he can fix them. No timeline for a patch date yet, except for soon(tm)... Just know the issue is one we're more than aware of, and it's one that we're constantly striving to fix. It's just not the simplest of things to sort out and correct, so it's still in our "pending correction" list and hasn't made it all the way into the "past bug" bin yet.
RE: Keyhit library update - SpriggsySpriggs - 02-10-2023
I don't use _DEVICES. I use the XInput API from Win32 so I can read controllers. Also lets me start up the vibration motors.
RE: Keyhit library update - johannhowitzer - 02-10-2023
Quote:What you've got looks a whole lot like my keyhit library, except it's not quite as advanced. What you're tracking is a single button's up/down state, to see when it might be pressed, while the keyhit code here does that and applies key modifiers to it.
The difference in a nutshell?
You report Shift-A as two key presses -- "Shift" is down, "A" is down.
This library reports Shift-A as two modified key presses -- "Shift" is down (it doesn't modify), "A" might be down, or "a" might be down (depending on CapsLock state).
What you are describing as "advanced" is exactly why _keydown and _keyhit ended up being completely unusable for my purposes, and why I had to turn to _button instead. In fact, what I proved conclusively in a test - and also submitted in a bug report a year or two ago - was that _keydown has an issue where a modified key will "stick." If you do the following:
1. Start holding shift
2. Start holding A
3. Stop holding shift
4. Stop holding A
...Then _keydown actually thinks the uppercase A was never released, since what was released on step 4 was lowercase a. The end result of this for my game was that if modifier keys were bound by the user, the controls would stick when more than one thing was done at once. So if you used shift for "boost," and A for "shoot," then sometimes you would enter a state where you would be pressing nothing but still shooting endlessly.
As for _devices, I can't really say, I do know that my game can't use the alt keys - if you look through the list of keys in my library, you can see all the ones I considered "safe" in my testing. _devices does read my USB controller, although I have not yet tested the game on multiple hardware setups and peripherals.