arrow() just contains the ASCII arrow key data. The arrow key section acts like a joystick and respects held inputs to aim 8-way, with "neutral" position resulting in aiming to the right by default (sidescroller like Gradius). I have an aiming indicator and this is behaving properly.
What's unusual is that this IS working for shooting in all of the 8-way input directions... except up-left. It will aim that way, but the spacebar isn't causing a shot to spawn. There is shot to ship collision, but every shot carries the index of the ship that created it - that's what the first parameter "0" is in spawn_shot, and the collision routine ignores matching ships and shots to avoid friendly fire, so the shot isn't immediately hitting the player's ship here.
EDIT: This is really weird. Further bug testing showed that only certain combinations of three keys do not play nice with _keydown. Specifically, it doesn't like up, left, and space together. When I held left, then added holding space, then pressed up, the aiming indicator did not move to aiming up-left.
Title: Re: Odd multiple input problem
Post by: FellippeHeitor on July 11, 2019, 06:07:51 am
You’ve found your keyboard’s hardware limitation to detect multiple keys down at once. https://en.wikipedia.org/wiki/Rollover_(key) (https://en.wikipedia.org/wiki/Rollover_(key))
You’re likely to get different results across different systems you’ll test your game in.
Title: Re: Odd multiple input problem
Post by: FellippeHeitor on July 11, 2019, 07:45:38 am
On my machine I can go all directions and still shoot with space. What results do you get with the snippet above?
Title: Re: Odd multiple input problem
Post by: johannhowitzer on July 11, 2019, 08:36:32 am
With your code, the lines turned red in every direction but up-left. "Key jamming and ghosting" section of that Wikipedia article seems relevant to my situation. Necessary to use the arrow keys here, but I bet keys other than spacebar will work well for "fire." Z has already worked - this is a common choice among some PC release shooter games, such as Touhou.
While QB64 won't be my final language for the project and I'm just doing proof of concept stuff right now, this is a hardware issue and I'll need to go searching for more complete info about keyboard jamming so this won't be an issue for people in the final version.
Thanks for your help!
Title: Re: Odd multiple input problem
Post by: TempodiBasic on July 11, 2019, 12:35:55 pm
Hi johannhowitzer
about
Quote
arrow() just contains the ASCII arrow key data.
look here what it happens to use a string data and convert it into integer with CVI function
Title: Re: Odd multiple input problem
Post by: johannhowitzer on July 11, 2019, 02:41:50 pm
Thanks, but I ran your program and it had the same issue as before on my laptop - it's a hardware thing. It's not something you can code out, as everyone's hardware is different; it's something you have to design your inputs around. Presumably it's why many PC shooters use Z for fire, perhaps the hardware conflict doesn't exist or isn't as common between arrow keys and Z.
As an aside, the arrow() array doesn't contain the numbers in string format, it contains the following, a throwback to my QBasic days.
Title: Re: Odd multiple input problem
Post by: TempodiBasic on July 11, 2019, 03:49:11 pm
Hi johannhowitzer
sorry but I don't agree more about hardware issue, I think that it is about code... (also because when I see some terrific combo used in some games I think of a player of piano and not a gamer)
make this experience with me
please run the original your code with your array initialization... well with my printing results modification you cannot get these combo keys
1. holding spacebar (32 keycode) AND 1.2 holding Left arrow key you cannot see UP arrow but you can get another combinations of two arrow keys AND viceversa if you hold together Left+ Up arrow key you cannot get spacebar keydown event 1.3 holding Right arrow key you cannot see DOWN arrow but you can get another combinations of two arrow keys AND viceversa if you hold together Right+ Down arrow key you cannot get spacebar keydown event
2. holding 2 arrow keys 2.1you cannot detect the third arrow key (Yes here someone can affirm " But this is illogic, why must someone press and holding 3 arrow keys in the same moment?" right as logic of programmer, wrong as function that must give back to me if a key is down and not if there is no more 2 key down!) 2.2 you cannot detect spacebar when you press together Left+Up or Right+Down...
in fact also using your newer array AS STRING *2 and initializing as you have posted, I got the same result of you, the third key holded is not always got by I/O functions... all this happens on a HP notebook 64bit windows 10 and CPU AMD E 450 APU.
I'll test on another Notebook later
Title: Re: Odd multiple input problem
Post by: FellippeHeitor on July 11, 2019, 04:40:52 pm
It’s a hardware issue, TempodiBasic.
Title: Re: Odd multiple input problem
Post by: SMcNeill on July 11, 2019, 05:53:51 pm
_KEYDOWN is limited by hardware restrictions. Most USB keyboards will never register any more than 6 keys simultaneously, due to USB specifications/limitations. (Some might, but require either custom drivers, or multiple virtual drivers, and both options are unreliable.). You’d need a PS/2 N-key Keyboard to read more keys than that.
The best way to handle this type of input is to use _KEYHIT, instead of _KEYDOWN.
Use _KEYDOWN to check modifier keys (such as Shift-Ctrl-Alt with work with normal key presses), and _KEYHIT to handle normal keyboard input.
A nice write up on N-key keyboards, rollover, and USB limitations can be found here: http://blog.controlspace.org/2010/08/n-key-rollover-what-it-is-and-how-to.html
Title: Re: Odd multiple input problem
Post by: johannhowitzer on July 11, 2019, 06:41:22 pm
How does _KEYHIT function with holding keys down, though? This game will involve holding down the arrow keys a lot for movement, and holding other keys as well for certain auxiliary functions. All of this is moot at the end of the day for my purposes, of course, since I'll be moving to Unity for this project soon. I appreciate the help, I've learned some important things here.
Title: Re: Odd multiple input problem
Post by: FellippeHeitor on July 11, 2019, 07:19:38 pm
KEYHIT returns a positive key code at key down, a negative key code at key up.
Wouldn’t likely help in the current case as the third key in the faulty combo won’t register in your hardware anyway.
Title: Re: Odd multiple input problem
Post by: Pete on July 11, 2019, 09:42:33 pm
Well, I don't know the PEEK state of the spacebar key, but I do know the value to detect Shift, Ctrl, and Alt; so, if you don't mid exchanging a Shift key for the spacebar, you could get a triple key detection with Windows API + a PEEK routine.
Now if you read the 4 columns of values, you will notice the API cannot detect more than 2 keys down, which means the way I set up the code, it fails to detect the Shift key when the arrow up and left keys are depressed. Well, fortunately, the PEEK statement can detect a Shift key press, even when the arrow up and left keys are depressed; hence, a triple key routine is possible with Shift, and maybe with spacebar, if anyone can remember the PEEK DEF/SEG routine necessary to detect a space bar press.
Pete
Title: Re: Odd multiple input problem
Post by: TempodiBasic on July 12, 2019, 08:52:13 am
Hi this is the results on another notebook [ This attachment cannot be displayed inline in 'Print Page' view ] yes on this program catch all _keydown in the same time!
and on the same TOSHIBA if I use an USB external Keyboard I have some other strange results!!
yes I must admit that it is an Hardware issue, no issue of language. (@Fellippe Thanks for tips) So both if I write something in C++ both in QB64 both in Python or whatdoyouwanttouse the results are the same depending on the hardware!!!
Title: Re: Odd multiple input problem
Post by: johannhowitzer on July 12, 2019, 01:14:45 pm
You've reminded me that I need to be careful of left+right or up+down inputs, thanks.
Title: Re: Odd multiple input problem
Post by: TempodiBasic on July 13, 2019, 11:16:16 am
Mhmmmm... _KEYDOWN is hardware sensible, Steve and Fellippe suggest to use _KEYHIT knowing that if key is released _KEYHIT returns a negative value...
Mumble Mumble.... it let me imagine...
this is a first result of a my attempt to write a workaround with _keyhit at the place of _keydown
for now as you can see from image I can get to see 5 key pressed together and holding them... [ This attachment cannot be displayed inline in 'Print Page' view ] but I'm fighting with _KEYCLEAR, it is the first time that I use it.
Stay cartooned / tuned
Title: Re: Odd multiple input problem
Post by: TempodiBasic on July 13, 2019, 11:57:21 am
Hi guys I think that this is a good solution... only if someone let me see where I must put _KEYCLEAR to void the buffer's tail :-((
Title: Re: Odd multiple input problem
Post by: Pete on July 13, 2019, 01:43:46 pm
Yes, the buffer is a huge problem when running the code. You can retrieve a single key entry by using _KEYCLEAR immediately after: comm = _KEYHIT ' memorize hardware input
I'm surprised this worked for you, because on my system, it will not detect more than 2 keys when I use left arrow + up arrow + spacebar. Now some other combos work, but the one mentioned left arrow + up arrow + spacebar needs to work to have a breakthrough. I wish I could remember a way to get PEEK to recognize a spacebar press. In my attempt, I had to substitute Shift for the spacebar, so I really can't say if a way to PEEK a spacebar press would work or not. It just isn't apples to apples... more like Apples to Windows. Anyway, only certain PEEK/POKE are still preserved, as this was all 16-bit stuff, back in the day. I did find that PEEK(197) worked to find a key press on a Commador64, but that lower rage is apparently ignored on non-16 bit systems. Oh well, that's "progress" for you!
Pete
Title: Re: Odd multiple input problem
Post by: TempodiBasic on July 14, 2019, 01:18:05 pm
Hi Pete about _KEYCLEAR it doesn't solve the problem of the buffer
if I put it just after _KEYHIT I got a strange effect ON OFF for the key pressed without any detection if the key has hold or no. If I put _KEYCLEAR in the area of waiting for new cycle after _LIMIT 10 and/or before _KEYHIT the program doesn't catch input from keyboard. .....
about my workaround I have tested it using an USB keyboard and it can catch only 2 arrow keys and no more plus! Also _KEYHIT seems to soffer of Hardware limitations. In this case I think that also using PEEK or INP there is no matter to do. Where the hardware fails there is not possible to use so combo! So for using professional games with combo using plus 2 keys , the user must use a gamer keyboard with no limit (like PS/2 as said in the article linked by Steve).
Well at my home, if I want develop a game with such kind of combo (more than 2 keys) I must use one of the 2 notebook TOSHIBA that with their inner keyboard let me catch all the keys I like to catch. But if I use an USB keyboard (I have tested 2 keyboards USB and wireless made by different manufacter [Sigma, Trust]) I fall in the hardware issue. While the 2 HP notebook show the hardware issue also with their inner keyboard.
Thank for reply Pete
In sum: the solution is use a power hardware for gaming or write a game with no such kind of combos.