Main Loop Start and Mob Farm+

Ah. After a bunch of effort creating the QuickBASIC/QBasic syntax highlighting script for Vim, I finally sat down to write the skeleton for the main loop of LED2-20. The first thing that I started on was the keyboard event trapper. According to my design document, I had to define 21 keys:

• 4 built-in for arrows;
• 4 for ``extended'' keyboard arrows;
• 4 weapon-related;
• 8 relating to utility functions; and
• 1 for quitting the main loop.

The key idea here is to use the event-trapping to set a bit-wise flag that the key had been detected to press. Then, when I reach the ``user interaction'' processing part of the main loop, I can consult the bit-wise flags ``all at once'' and deal with them. This allows the processing of the so-called chorded keys, i.e. having more than one key pressed at once. Using the old method of reading directly from INKEY$ led to all kinds of synchronisation problems, among which was the sheer impossibility of tracking chorded keys.

The proper tracking of chorded keys is important for movement. One of the old-school bugs/features of the day is the unintentional speed boost from chording two or more directions at once. Usually the keys provide only 4-directional movements, with each key adding one unit of movement in their associated direction. This means that if I chord [say] the right and down keys, I end up moving at a distance of about 1.4 in the down-right direction, as opposed to moving 1 in the the down-right direction. If the movement units are singular (like just 1 unit), then it doesn't matter too much. Since I am intending to allow the player to change the maximum thrust power of the LED, this boost is definitely unintentional. With the method I stated, the direction keys now provide the correct interpretation of setting the direction, and more importantly I don't need to spend much of my interpreter time polling the keyboard via INKEY$ and do weird math to figure out the chording.

In QuickBASIC/QBasic land, there is a need to differentiate between interpreter and behind-the-scenes run-time. Interpreter run-time is necessarily slower, since each line of code translates to multiple lines of machine code, whereas behind-the-scenes run-time tend to be more efficient since there is little to no translation time required to get it to run on the metal. That's why during the later parts of QuickBASIC/QBasic's run, near the end of the Windows 98 era, assembly-based libraries like DirectQB and FutureLibrary were a thing. At that point, much of the main-loop and rendering engine is handled using behind-the-scenes run-time, while the game logic is still handled at the interpreter level.

I could use those libraries for LED2-20, but that's not the purpose of this retro-programming project.

Anyway, I wrote up the basic MAINLOOP.BAS, and used it to test the qb.vim file, doing more fixes along the way to both and publishing the updated qb.vim file as and when I reached some kind of milestone. One thing I learnt along the way was the idea of a ``dotted filetype'' in Vim, where one can define a chain of syntax highlight scripts to load in left-to-right order. I learnt about it solely to fix the problems that NERD Commenter was having when I used qb.vim only. The problem was that NERD Commenter was expecting something called ``basic'' in the filetype system variable, and not seeing it, defaulted to using C-style comments.

And that's about it for the retro-programming bit for now.

------

In Minecraft, I've finally started building up the item auto-sorter and the two automated sugar cane farms under my mob farm. They were surprisingly easy to build, and I had finished it within a couple of hours of starting. So now, when I AFK at the mob farm, I can get bones (good for bonemeal for an empowered manual tree farm), arrows (good in general), gunpowder (great for rockets needed to fly in Elytra), and sugar cane (can be crafted into paper to make rockets).

Maybe the next Minecraft project will be to build me some nether-rails. That one will involve some adventuring and careful math. Another project might be to use my Elytra to find some other biomes containing other useful materials that I still haven't seen, like bamboo.

Anyway, that's all I have for now. Till the next update then.