Thursday, October 14, 2021

Manipulating Pixels

Ah, Thursday.

The weather is still nut-so, but what can I do about it? Anyway, the weather has been bad enough that I had to bring out the four laptop ``leg'' stands. I had put those away for quite a while because the angle that I was using them that allowed a better channeling of wind (tilted away from me) was screwing my wrists. The ``as-designed'' angle was really to have the laptop tilting towards me, with the rear raised higher than the front, but the problem with that was that the fan on the right side of Eileen-II would randomly sound like it was rubbing on something bad, causing some scary sounding vibrations.

Previously when those vibrations came about, I would hastily suspend Eileen-II before opening up the back cover, and try to clean out the dust. Then it got a little bit more frequent than expected, but I realised that if I left it alone for a while, the fan would eventually slow down/stop, and the next time it restarted, the vibrations would be gone.

Well, today the vibrations happened again. I was annoyed enough that I took apart the back cover and stared at the fan again. Back in the day, I would take the fan out from the casing and lubricate the moving parts, but the way Eileen-II was set up, it was very risky to take the fan out completely. But I realised that there was just enough leeway to get some lubricant in, which I did, carefully. My lubricant of choice was, of course, Vaseline, mostly because it is non-conductive. I slipped some of it in, and after putting things back together and setting up the legs ``as-designed'', there hasn't been any major vibration incident.

A win, perhaps?

Anyway, it was comfortable enough to type on, and I worked a little on LED2-20. I got the right-rectangle (rectangle with edges parallel to the screen edges) intersection sub-routine working, and with that, managed to get the ``put sprite anywhere on screen'' sub-routine working. The problem that I had to solve was that the built-in PUT graphics statement automatically fails if any part of the bitmap image exceeds the boundaries of the screen. This means that, for example, if I have a 16×16 sprite, I cannot use PUT with the upper left corner being at (−10,−10). But in LED2-20 (and other games), we should expect ``partial'' sprites to appear on screen for that immersion. My solution to this was to grab the reduced sized bitmap (and mask) on the fly and use that with QuickBASIC's internal PUT statement.

It works well enough. I did switch up the way I separated out the cases though, relying on error-trapping to handle the cases where the more time-consuming bitmap handling was required while avoiding the cycles spent on validation checking before using the PUT graphics statement in the beginning. This can be quite a time saver in the long run when considering just how often we are drawing sprites on the screen.

So at this point, keyboard handling, and basic sprite/background renderer (the background renderer is similar to the sprite handler, but without the mask) are done. I'll probably need to worry about pixel-perfect collision testing next, or think about the game data structures that I need---either way is fine.

------

In Minecraft, I dug out another row of rocks from my mine, and built a glass enclosure for my bees and flowers. I had to do that second bit because the damn bees kept on disappearing. They first disappeared because they kept on running into my lava wall (I removed that), and then they probably disappeared because they wandered too far off from my service platform and didn't return or something.

Anyway, that's about all I want to talk about for now. Till the next update.

No comments: