Day 023: INKEY$
#2
"INP(), PEEK and POKE", eh? "INKEY$" was always one of my favorite functions but with that keystroke buffer I considered a PITA. Without a buffer, however, say on the TRS-80 Color Computer, sometimes the computer was unresponsive thanks to the slow interpreter.

Note that porting to other BASIC's could be a headache, such as Freebasic developers' decision to change to CHR$(255) from CHR$(0) the first out of two characters returned by arrow key or such other key. The CHR$(255) + "k" (lowercase "K") combination then could be used to trap the "X" on the right-hand corner of a window, for a program compiled in GUI mode.

Despite attempts to phase out "INKEY$" this is a stronghold for beginners. A great many programs still use it and don't resort to "cheating" by looking at input ports and special memory areas. However, a game that has to look and act professionally such as an RPG requires extra strength interacting with HID. I have experienced this. I have to go look for the source code of a program that mimicked a good game I played on the Apple IIe. The response is a bit late because it uses "INKEY$" and also involved "_LIMIT" used inside a loop. This was already discussed sometime ago.

I had created another game which could have produced laughter if I shared it here, because it was supposed to convey the sense of speed. Some spaceship travelling "forward" through space either slowly or quickly, through "obstacles". But it doesn't do it by scaling "_DELAY" and it doesn't use "_LIMIT". The way I did it, I think would cause someone to say, "This game was done by a n00b!" Actually it's a work in progress (was done in 32-bit Linux with Freebasic).
Reply


Messages In This Thread
Day 023: INKEY$ - by Pete - 12-03-2022, 07:18 PM
RE: Day 023: INKEY$ - by mnrvovrfc - 12-03-2022, 11:58 PM



Users browsing this thread: 3 Guest(s)