Mending Auto-sorter & Lenna

An early-ish update for today: I managed to figure out a fix for the item auto-sorter overflow handler in Minecraft. Consider the following schematics for the redstone filter circuit I am using (reproduced from here):

Main reason for using this is the compactness in the layout, and the relatively few items that need to be stored in the filter hopper (R1C4), but that aside, look at the hopper in R2C4. When that hopper gets completely full, it transmits a signal strength of 15 through the block at R2C3, which eventually messes up the comparator signal at R1C3, leading to a shut down. That's what it means by being ``not overflow protected'', a feature tha I didn't realise until I started to have to worry about this.

My solution is to put a solid block at R1C5 with a switch, which effectively blocks the filter from working through locking it with a redstone signal. This means that when the object of the same type passes from above (the hopper chain not pictured at R0C4), it will not be pulled by the filter hopper at R1C4, and will merrily continue on to get to the other auto-sorter which filters out excess things that I want to send to the incinerator. The item generation rate of my mob farm (and bamboo farm) isn't great enough that I don't have the time to manually set that switch, and so this solution is good enough. With that implemented, I promptly demolished that branching hopper train that I built for the bamboo farm.

The next highest rate of item generation is the sugar cane farm, and the problem with that was that it fed into its storage system directly as opposed to going through the main item bus. Space in the warehouse portion of the mob farm was really tight, and I ended up building a dual-switch version of the shunt I originally implemented for the bamboo farm. It works well too. Wonderful.

------

I mentioned earlier about thinking about how to generate/handle the far parallax background, and talked about how I would use Pillow to generate it. Well, I put together a hastily written program in Python3 that generated something that could be plotted in QuickBASIC using the default colour palette. Here's a rendition of the infamous Lenna in SCREEN 7 with EGA 16 colours:

Overkill? Maybe. Remember, the idea here isn't to go full caveman mode, but to use the retro-technology to build the actual game that will be LED2-20 while applying the knowledge that I have gained over the past 20 or so years. If the assets can be generated using other more effective means, then it would be silly not to do so, since it does fall into the whole ``knowledge gained over the past 20 years'' category. I draw the line at [programming] language translation though, so I won't be doing things like writing LED2-20 in QB64 or FreeBASIC or even some flavour of C/C++ and back-translating it to QuickBASIC.

The game itself will be written in QuickBASIC, and potentially compiled to run in DOSBox as a 16-bit program. Now whether it will run well under 80286 is not part of the equation---I'm not willing to go that far, because it will mean bringing in more forbidden techniques of a bygone era (hello MASM my old friend) at which case I might as well just write it for a modern system in the first place. Any other tools that I use that fall outside of old school MS-DOS of the day are not part of the ``retro'' limitation that I am setting for myself.

That's about it for now. Till the next update.