Home Games Words Events Other

Digitiser: The Game: Development

Part 3 - 29th June 2018

< Previous  Next >

Do you remember when I wrote that work on this would start in August, with release tentatively scheduled for November this year?

Well, that period included a one-month buffer, which is being eaten rapidly from both ends. Right now, another game that I'm working on is slipping behind schedule. It needs to be done first, because I'll be using its tuned engine as the basis for the Digi game. At the other end, I've had some dangerously ambitious ideas. Even after allowing time to fully consider what's feasible, I'll still probably end up adding delays through daft features.

In the worst case scenario, and subject to approval from Mr. Biffo, I'll bring a not-too-spoilerly demo version to the Digitiser live show. Which is all very well, though he was wise to hold back that £2.99, and such excuses cannot dispel the Golden Tears of Molyneux.

Today, here's the first part of a peek behind the scenes of the secret teaser video that was poorly publicised to Kickstarter backers. This entry is pitched primarily at those who wish to merely dip their toes in technicalities, so I'll be saving some game engine details for the next diary.

Readers who are disappointed by that missed opportunity for a peek/poke joke can go here for buckets more detail. Except that's an old version of the engine, so they should also come back next time to see how much (little) has changed.

Bar coding

Here's a still from the same teaser, but with some additional coloured bars. In brief, the television picture is constructed by a beam that scans from top to bottom of the screen, and the game code changes border colour each time it finishes doing a job. So, the height of each bar indicates how long each job takes.

The top bar, in blue, is time spent generating the blippy walking sound. The ZX Spectrum has no dedicated sound hardware, just a tiny speaker wired up to the processor. During the blue period, this processor is busy flipping the voltage of the speaker at the desired frequency.

The next bar, in red, is time spent wiping the last position of the stealthy miscreant. The ZX Spectrum also lacks dedicated graphics hardware, so this is done by using the processor to write zero throughout the corresponding area of video memory. This also wipes the part of the background where the miscreant was last standing.

So the next bar, in magenta, is spent redrawing part of the background. The movement area is mostly blank, so to speed things up, only the bottom parts of the streetlights are redrawn this frame. Each is the size of the miscreant, but redrawing is slower than erasing, mostly because filling memory with one number is faster than copying a set over.

Then, during the green bar, the miscreant is drawn in their new position. Their blocky movement is due to the ZX Spectrum storing numbers as eight bits, which correspond to eight black or white pixels in video memory. Moving in eight pixel steps keeps things aligned to whole numbers, which is much faster than splitting pixels across two numbers.

There are two drawing passes, because some pixels are transparent. The first pass clears the silhouette, so that the second pass can fill it without messing up the nearby background. Accordingly, this takes longer than completely wiping an area of the same size.

Stay away from my .bins

The cyan bar was spent checking if the miscreant was at the bins. It was relatively short, because it turned out that the bins did not redrawing, so here's how the bars change size when filthy rummaging is in progress.

The blue bar has grown because the rummaging blip is lower pitched that the walking blip, so takes longer to play. The red and green bars are the same height as before, because the miscreant is erased then redrawn regardless of position. However, the magenta and cyan bars have swapped size now that the bins, rather than the streetlights, are redrawn. The bins are smaller, though partly transparent so the miscreant shows through, hence the drawing times even out.

To understand how colour works on the ZX Spectrum, consider the video memory as having two layers. The bottom layer is a relatively high resolution monochrome picture, and the top layer is a low resolution colour overlay. Which, if you remember attribute clash, could cause pixels on the bottom layer to fight for colours on the upper layer, unless the game moved everything in chunky steps to match the colour resolution.

This teaser demo doesn't change the colour layer at all. Instead, the miscreant inherits colours depending on where they are on the screen, which allows crude lighting effects for no extra processing cost. Also, all erasing and redrawing happens only on the pixel layer, the colours left untouched.

Script for adjusting Tears

Extending the cyan bar across the width of the screen would just clip the top of those bins. This means that, currently, the code is just fast enough to draw everything without tearing (the bins are drawn from top to bottom, otherwise their lids would already be torn.) In short, it needs drastic improvement to support more than one Digi character doing their thing.

Fortunately, this teaser was merely hacked together in a week on an unsuitable engine, and I already know where to start bashing things into shape. As those of a less technical inclination may have died several paragraph ago, I'll save the details for another time. For the survivors, I'll move on to some retro history, featuring better games that you can play right now.

Enquiring minds may be wondering what happens if parts of the low resolution colour layer are changed while the television beam is passing. The answer is, funky colour tearing, like this.

This is from Amaurote, in 1987. It was written by Mr. Biffo's very own 8 bit survivors, the Pickford Bros, who will no doubt inform you if I'm talking complete rubbish. Give them a few minutes, they're probably still nauseous from the earlier coding horror show.

Anyway, this is a static screen, so the processor is free to tweak the colour layer faster than the television beam can draw it. This looks much better in motion, with lines pulsing up and down like psychedelic interference, but is still essentially a static special effect. For game developers in that era, attempting to coordinate such colour changes with moving graphics would have been crazy.

Don't tell J. Michael Straczynski, but it was far simpler on the Amiga, which had hardware dedicated to modifying colours in the middle of a frame. For example, most games would draw the sky as a gradient, which was achieved by listing palette changes to be made at particular television beam positions.

Bad Things, Good Things

There are many modest, talented people in the ZX Spectrum scene. I'm fortunate that Mr. Biffo didn't ask one of them to make this game instead. I largely avoid most new developments, in an attempt to stay focused on creating something uniquely shoddy. However, one name stands out for wowing with technical wizardry, while doing more valuable work in the background.

It's hard to ignore the ZX Vega+. Which didn't stop one archive site from trying, until the money ran out. Fortunately, Einar Saukas has created, and maintains, an open source database of game information. Spectrum Computing makes excellent use of this, and if they disappeared tomorrow, the core data would remain safely accesible to all. His combination of hard work, foresight, and generosity is a tonic for all the recent bad things.

When he's not rebuilding foundations, Einar likes to make game engines that tickle hardware into doing what it was never designed for.

That's the copyright-skirting Pietro Bros, running on a stock 48k ZX Spectrum. The engine can't entirely solve attribute clash, but stunningly quadruples the vertical colour resolution.

The inevitable trade-off, with the processor spending about half its time precisely juggling colours, is that games using this engine can move less things about. However, it's ideal for more sedate games, like the cunning Snake Escape, which leads on to what I consider one significant strength of the ZX Spectrum.

Because it had little custom hardware, it was equally bad at everything. Colour overlay aside, game designers weren't nudged in any direction. This resulted in a diversity of styles compared to consoles, and even the C64, which tended to encourage games that favoured smooth background scrolling and hardware sprites. So, regardless of quality, I'm hoping that the Digitiser game will at least look distinctive.

Email: comments at arbitraryfiles.com