Tvaders

[mnrvovrfc]

Please correct me if I am wrong... would not 'inkey' provide a quicker response than 'inkey$'? Reason: When changing directions, there is a momentary pause, before the ship moves... unless 'that' is the desired effect... If so, just ignore the suggestion... Now... Let us talk about sound... Nah. Kidding. "Text" sound effects are great!

Perhaps you meant "_KEYDOWN()" instead of the first "inkey"? Response to user input is difficult to get right in a game, and in a programming tool for hobbyists this is noticed most easily. In QB64PE is because "_DELAY" or "_LIMIT" must be used to free CPU cycles and to wait a little bit to give the user some time to react to the bad guys. The "FOR... NEXT" loops that had to be used in ancient BASIC's also held up keyboard input.
I've tried to set up a loop of, say 10 iterations doing "_DELAY 0.01" and polling for a key each time but the response was a bit less sluggish than the "simple" method of only one "_DELAY", or a "_LIMIT" controlling the main loop of the program. I created a game that I will post on these forums in the near future, which illustrates the problem with reacting to user input quickly. I almost forgot to mention that the time has to be taken into account processing how the bad guys move and, in addition, if the game board is to react to what the user does (for example going from one room to another in a dungeon). M$QB had the "KEY() ON/OFF/STOP" crew but that was a dangerous way to program and, for an EXE file, it required a compiler switch which added overhead. "Dangerous" because if the screen was drawn slowly and it had to update everytime the characters moved in the game, pressing a key would have revealed a visual glitch or else worse.
The OS has to cooperate for "delay" requests 20ms or even smaller, which is another thing to try to beat.
Another thing is that I noticed the QB64PE IDE is sadder on Linux than on Windows with user input, especially holding down a key for a few seconds. Sometimes on Linux (doesn't matter which distro) the input is late. It must be the reliance on the ancient terminal and graphics code borrowed from Unix and the difficulty of providing an input method which is more efficient, for the fear that it makes things incompatible. I don't know how is it with you guys able to spend thousands of USD on quad-core CPU with 8GB+ RAM and so on.
On Ubuntu for example it might be better to disable key-repeat globally in the OS, only for the sake of keeping some sanity using the QB64PE IDE. But some people don't like punching the same key more than 20 times if not the space bar in a first-person shooter...

By the way... am I permitted to add a little colour? (I like the 'green' / 'light gray' text of the old monitors)

I agree with you as long as the background is green and the ALL UPPERCASE text is black, like my Color Computer.
https://colorcomputerarchive.com/xroar-online/