QBA24. - Alien Bastroids Attack! (Typical space shoot-em-up, `a la QBasic!)

[@NurchOK]

8:40 I believe CHR converts ASCII code into the character, not the scan code. Please correct me if I'm wrong.

[@dr.doodlesqbasicasylum8709]

You raise an excellent point, and you are absolutely correct; CHR$ does indeed convert Ascii codes to characters, not scan codes, EXCEPT when used with user-defined keys. According to the QBasic help file, (click "Index", then "Key (event trapping)" and scroll down to the "Declaring user-defined keys" link); To declare a user-defined key, use the following variation of the KEY statement: KEY n%, CHR$(keyboardflag%) + CHR$(scancode%) n% A value in the range 15 through 25 that identifies the key. keyboardflag% One of the following values, or a sum of values, specifying whether the user-defined key is used in combination with the Shift, Ctrl, Alt, NumLock, or Caps Lock keys, or with extended keys: Value Key 0 No keyboard flag 1 through 3 Either Shift key 4 Ctrl key 8 Alt key 32 NumLock key 64 Caps Lock key 128 Extended keys on a 101-key keyboard To specify multiple shift states, add the values together. For example, a value of 12 specifies that the user-defined key is used in combination with the Ctrl and Alt keys. scancode% The scan code for the key being declared. See Keyboard Scan Codes. See Also KEY (Assignment) KEY, ON KEY (Event Trapping) The reason for this is to ensure that the keyboard will perform the same, regardless of what code page (language) is installed on a given computer. For example, If I write a program to respond to the "F" key on an English keyboard, it should work properly on any computer with an English keyboard. However, if a computer is set up for Arabic, or Yiddish, or any other language, it won't know how to interpret that character. On the other hand, scan codes refer to specific keys in hardware, regardless what character that key may represent. Hopefully, this was not too confusing, but thank you for your excellent question, and I hope I have answered it fully! Thanks also for watching & as always, have FUN programming! (Because, if it ain't fun, it ain't worth doing amiright???)

[@NurchOK]

​@@dr.doodlesqbasicasylum8709 Interesting. It has been many years since I've done anything at all in any flavour of BASIC language. This one thing I did remember distinctly, but had no idea it could also be used for scan codes. I stand corrected. 👍

[@dr.doodlesqbasicasylum8709]

@@NurchOK Well, yes & no - I mean, you WERE right - this is just an exception to the normal use of Chr$, to my knowledge, the ONLY exception. (Which is exactly why I mentioned it in the first place.) And honestly, I had no Idea either, until I started working with user-defined keys. That's the beauty of programming, in ANY language, really - the more you do it, the more you learn!!

[@Notarget1337]

Great vid! I think it's way too fast though. Maybe try downclocking the cpu to somewhat around 66 MHz. I would imagine this machine is a bit fast. Is there any way to use not the cpu cycles as a time counter but delta time?

[@dr.doodlesqbasicasylum8709]

Thanks for the kind words! And yes, it does get pretty fast, but that's part of the challenge - otherwise you'd just be shooting baddies all day long! If you like, you might try starting with a longer delay to begin with, and then reduce it more slowly, maybe just 1 less delay per level. My machine lacks a "turbo" button or anything, so I've no way to "throttle" it back, though if you're running through DosBox, the frame rate can be reduced quite a bit. The Timer function is the most accurate method I know of in QBasic, and the most consistent from system to system, since it's tied to the real-time clock, not processor speed. Often I'll just use empty for-next loops to slow things down, (example: For X = 1 to 1000: next X). True, this technique is dependent on processor speed, so on faster systems, it can run TOO fast, but it's quick & dirty, and simple to program, so I use it quite a lot. (Probably TOO much!) I'm glad you enjoyed the video & thanks again for commenting! Don't forget to download the code & tinker with it - see what you can do with the speed issues. And, of course, I welcome you to share your work & ideas with all of us here in the Asylum! Cheers for now! Hope to see in the next one!