This month was an attempt to break from the usual routine, because focusing on something else occasionally can be productive. So, it was off to Block Party 2018, and taking those few steps back did reveal the way around some tricky problems.
Beforehand, I was busy preparing two project for the Raspberry Pi, both written using Python and Pygame. If you're seriously considering making your own games, then that's all you need to begin. It will be a learning process, and the results won't be spectacular, but it's both a fine taster and solid foundation if you decide to go further.
The first project, shown on the left of the screen, was porting some old software that displays images from the Raspberry Pi video camera in the style of teletext. This was originally written in C, and getting it going was far too much hassle for the uninitiated. Since then, I'd written nearly all my ZX Spectrum development utilities in Python, which just works out of the box on a Pi.
The second project, shown on the right of the screen, was an impulsive indulgence. After using Pygame in a simple way, to display the camera output and read the keyboard, it seemed good enough for making actual games. So, I allocated one week to try something stupid that isn't finished, but I'm open to suggestions that it may be worth completing.
The catch with speedy development in Python, and many interpreted languages, is slow execution. Most are converted to machine code on the go, and typically in a flexible but inefficient way. This doesn't matter for Spectrum development tools, which still only take a few seconds to process what is usually less than 48k of data, but was problematic for real-time video processing.
Another issue, though not specific to interpreted languages, can be reliance on libraries. These are collections of code that someone else has written, and usually reduce complex processes, like capturing one image from a connected camera, to a single instruction. Which saves having to know any low-level details, until they can't do what you want. For example, Pygame's camera library couldn't talk to the Raspberry Pi camera, while the standard camera library could only supply video frames at half speed.
Then, it turned out that pixel processing was at least one hundred times slower when using vanilla Python, rather than C. One particular Python library, itself written partly in C, was ten times faster for one step, but unsuitable for the others. Which is not to discourage novice programmers, because Pygame has fast-enough libraries for most 2D work, just something to be aware of before pulling back the covers to implement grander ideas.
I'm learning that balancing priorities is no less important than programming and drawing. It's not worth spending days making a rarely-used tool run in microseconds, rather than seconds, and pruning a paper script can save far more precious memory than fine-tuning compression routines. Some decisions are harder, such as choosing retro authenticity at the expense of easier development. We'll find out if that was a mistake soon enough.
This is a peek at the still-not-finished other game, crawling down development road, though it was at least far enough to demonstrate at the teletext gathering. There's a bit more to that illustration than meets the eye, with little tweaks of life happening over time, but it still took one working week to draw. Partly because I'm learning pixel art as I go, but even so, if Mr. Biffo worked like that, Digitiser would have been a monthly feature.
So, it was quite liberating to spend one rather long evening creating this advertisement. The process was hastened by poorly redrawing someone else's character, which even if they can recognise it, was hopefully an acceptable transgression for the greater glory of Croydon. Which really is the last known location of some important Prestel servers.
It also helped that precision pixel drawing feels easier with a keyboard, rather than mouse, because there's no need to refocus on accurately positioning the pointer. So much easier, that I'll probably write a program to convert teletext files to background graphics.
I now draw your attention to the text characters in the earlier monochrome picture, which appear too spread out horizontally. This is because they align to the Spectrum's 8 by 8 pixel cell format, which as detailed in earlier entries, is the fastest way to draw and move. Top of the Digi game wish-list was to render text at a more pleasing 6 by 8 pixels, and therefore 40 characters per row, just like teletext.
However, despite considering using some scaled-up graphics in the Digi game, I didn't think that the Spectrum could display graphics in true teletext style. Until I saw that happen, live, via an ancient teletext adapter. Alistair Cree explained the reasons, though it took a few days to realise how one quirk of teletext solves the problem of dividing 8 by 6.
Working from left to right, six pixels fit inside the first eight pixel cell. Adding six more pixels spills four of them to into the second cell, two of another six spill into a third cell, then six more fill the rest of that cell. This pattern then repeats every three cells.
Assuming a fixed background colour, the Spectrum cannot show two different coloured sets of pixels in one cell. However, the most commonly used teletext colour control codes prevent that situation, by creating a six pixel gap between different colours. The new colour then always begins in the next eight pixel cell, regardless of the step in the pattern.
The next problem was dividing 8 by 3, because teletext graphics characters have a resolution of 3 by 2 pixels. The middle pair are actually slightly taller than the top and bottom ones, so my first attempt was a 2-4-2 split. Which resulted in the weirdest test image, whereas 3-2-3 seems the best compromise.
Teletext also solved part of the dilemma of an off-screen drawing buffer, which at full resolution, would require 6k of the available 41k. The lower vertical resolution dropped the requirement to 2.25k, though the horizontal resolution is unchanged. Because, as you might remember, splitting groups of pixels across eight pixel byte boundaries is slow, so best done entirely in the buffer.
The test image also features some equal aspect ratio versions, partly for comparison, and also because I might need to scale things down for crowd scenes. Or up, though there are currently no plans for Lewis to destroy Tokyo. Again, rewriting the script, or at least framing crowd scenes in close-up, might turn out to be the best use of resources.
I'll mostly be working on the remaining graphics for the boring game next month, though will take one week out for a final pass on the Digi game script, before it goes to Mr. Biffo. Who is deep in editing the show, so might not read it too closely, which is fine by me.
The story and characters are in place, so it's about ruthlessly tweaking or cutting ideas from the script, if there's little prospect of realising them. You know, like checking what else Pudsey can do before commissioning the movie.
Email: comments at arbitraryfiles.com