Skip to main content

RR #4 - Running The Numbers

Much as I love the ZX Spectrum series of computers, I can't deny its screen setup is not ideally suited to games. For starters, its resolution - 256x192 pixels, very firmly in the 4:3 aspect ratio of UK TVs at the time - is smaller than both of its most popular 8-bit competitors, and a fair middle ground for handling both horizontal and vertical layouts. By comparison, the Commodore 64 and Amstrad CPC run their screens at 320x200 in 'high res' mode (albeit just 160x200 in 'full colour mode'), giving an aspect ratio of 16:10, coincidentally rather similar to the 'widescreen' format of today. It's interesting to note, though, that the Spectrum's resolution is somewhat closer to the average arcade game of the 80s, which would have been 256x244 (or 244x256 in Tate Mode), an aspect ratio of 8:7.

The Spectrum's screen is further broken down into 32x24 attribute blocks of 8x8 pixels, each of which can accommodate just two colours, designated INK and PAPER. Ideally, everything has to be kept within those attribute squares, whether coloured or not, so sprites and scenery components tended to come in multiples of 8x8 pixels in size, for convenience. Then, without any dedicated hardware for scrolling or throwing sprites around, everything has to be handled by the single Z80 processor at the Spectrum's core.

The gameplay window in Reckless Rufus is made up of 7 rows of 13 tiles each, allowing up to 91 tiles per level. This seems like a weird choice, but it fits the C64 screen rather well. Each tile is 24x24 pixels (technically just 12x24, as they use the C64's 'full colour mode'), thus occupying 312 pixels across and 168 down the screen, leaving 8 pixels horizontally and 32 pixels vertically. The remaining horizontal space is taken up by the timer, in the form of a bar, on the righthand side of the screen, while the remaining vertical space holds the UI panel at the bottom. Exactly the same arrangement is used for the Amstrad CPC version.

Now let's break out the maths and try to translate that to the Spectrum.

To accommodate 13 tiles across 256 pixels would make them each 19.7 pixels wide. Obviously, fractions of pixels are not a thing, and we can only round that figure down, to 19, since 13 lots of 20 pixels is 4 pixels wider than the screen... However, 19 pixels is 3 pixels wider than 2 attribute squares, so you're forced into monochrome presentation already, or the tiles could not be consistently coloured. It also only leaves 7 pixels on one side of the screen for the timer bar.

How about evening it out, and making tiles just 18 pixels wide? That's still 2 pixels wider than a pair of attribute squares, but fills 234 pixels, leaving 22 pixels columns spare. With that, you have options like a single, wider timer bar, or one on each side of the screen, or moving some UI elements, such as the ammo counter or score, to one side, opposite the timer bar. Let's make a note of that for a later post.

Now let's look at the height as well, just to be sure. Assuming a UI panel of 32 pixel in height, you're left with 7 tiles within 160 pixels, making each one 22.8 pixels high. If we call that 22 pixels, that's 6 pixels taller than 2 attribute squares, so we're definitely stuck with monochrome presentation. It also leaves 38 pixels free within the height of the screen. Sure, that can comfortably accommodate a 32 pixel high UI panel... but leaves 6 rows of pixels spare between the UI and the game window, or there's the option of making the UI panel 38 pixels tall... Not bad, but not ideal. Let's make a note of that for later as well.

Just to cover ourselves, how about making the tile height 23 pixels? The game window then becomes 161 pixels, leaving just 31 pixels, 1 pixel row shy of the 4 attribute blocks the panel ideally needs. You could probably get away with that, since the bottom row of the tiles is blank space anyway, to ensure some visual separation between each row, and it wouldn't necessarily have any significant impact on colouring the contents of the UI panel.

However, the coder correctly identified that the best plan for the Spectrum conversion was to keep the play area's 13x7 tiles within the attribute blocks, and set the tiles to be 2x2 attribute blocks, or 16x16 pixels. Unfortunately this made the total play area a mere 208x112 pixels... leaving 6 attribute squares - that's 48 pixels - of space across the screen and 10 attribute squares, a massive 80 pixels, from top to bottom.

So you can see why the Spectrum version has such an insanely oversized UI panel, and a timer bar on both sides of the screen:

Yes, that's the same level as the other two!

While I was pretty happy with the UI panel I designed back then (somewhat less so with the amended version that made its way into the finished game), there are many elements I wouldn't do the same way these days. Not least, the miniature 'screen' I used to house the lives/bullets counters, which is only 10 attribute squares wide, reducing the number of shots the player can take by 4. Given that it's possible to finish most, if not all screens without firing a single shot, that's not necessarily a huge handicap, but it was something the coder - quite rightly - called me out on. I think I balanced the screen vertically well enough, since it's traditional to have a larger UI panel either above or below the play area, rather than having, effectively, two panels of equal size. It's also not as if the C64 version was perfectly balanced horizontally, but the minimalist presentation means everything has some breathing room, where my Spectrum UI panel feels rather crowded, looking at it 30-odd years later. I can't even blame whoever tweaked it because, looking back, I can't imagine what was going through my head when I designed that UI panel... other than perhaps "I don't know what I'm doing, I hate designing UI panels, I'll just make it look as thrown-together-electronic as I can..."

So I'm sure you can imagine why I wanted to avoid this on a SAM conversion, especially since MODE 4 isn't constrained to or by any attribute blocks. To be honest, it would be possible - perhaps even easier - to adapt the Spectrum game to MODE 2 on the SAM, since the attribute clash would only become apparent in horizontal movement, but steps could be taken to minimise even that. However, MODE 4 is what looks best on the SAM, so that's what I was aiming for... and using the Spectrum UI panel was definitely not an option I wished to pursue. This would have to be completely new and purpose-built.

The obvious starting point was the C64's minimalist UI panel, since it would be easy to reproduce, and even improve upon... However, there's still the issue of the 64 pixel deficit in relative widths. For simplicity's sake, I decided to lock as much as possible of the UI to multiples of 8 pixels. At this point, I put my mathematics hat back on, figured out what I needed to fit into the available space, and then worked to determine how best to do that...

...Starting with Rufus having his full complement of 14 bullets. These are animated on all versions of the game, and I decided that all I really needed to do was add some shading to the 8x8 pixel spinning sprite I had created for the Spectrum version. That meant that the central section of the UI could be no less than 112 pixels wide. Next up were the beating hearts, three of which must be collected to grant Rufus an extra life. Again, I saw no reason to do anything other than tweak and recolour the Spectrum sprites for these, since the existing size - their frames of animation neatly fitting within 16x16 pixels - was already ideal. Three of those would occupy another 48 pixels of screen width. Assuming I was to keep the four columns that frame the C64 version's UI and separate its sections, that's another 32 pixels of width, bringing the UI, minus the score, to 192 pixels wide. Given that the score counter is just six figures, the remaining 64 pixels of width would be ample to fit them in, with the individual numbers being no more than 10 pixels wide.

Another of my gripes about the Spectrum version was that I cobbled together an 8x8 pixel font - based on the characters I could see in the C64 game - and a secondary font, larger and bolder, like the C64 version - just for the score counter, but that evidently wasn't practical, as the finished game used the same numbers I created for the main in-game font. I gather that kind of feature is a lot easier to accommodate on the SAM, where on-screen text often isn't actually text in the same way you'd see it and PRINT it in BASIC anyway. To this end, I brought out my old numerals font and spruced it up, to match the two-tone look of the C64 game. Putting all the elements together, the end result was this:

It ended up as only 31 pixels tall, for reasons which may be apparent if you recall my number-crunching about the tile sizes in the game window, earlier in this piece. Nevertheless, it comfortably accommodates the full set of readouts from the C64 game while, in some places, improving on the colour/shading of the original C64 game. The score numbers are nice and chunky, though not quite as chunky as the C64 version, and the whole thing has the vibrancy of the CPC version, without the reduced pixel resolution.

Hurrah for maths, and taking the time to structure one's pixel art.

Comments

Popular posts from this blog

TLC #8 - Keeping Score

Manic Miner is not a game know for an elaborate, intricate, stylish or elegantly-designed UI so, on that point alone, the existing SAM version manages to be an improvement on the original. Willy's air supply is represented by a couple of compressed air cylinders on the right rather than a simple bar running most of the width of the screen. Lives are represented by large, cartoonish (and, to me , somewhat creepy) heads rather than copies of the Miner Willy sprite. Score and high score were deemed worthy of their own font – a pleasant, calligraphic font using the shades of grey available in the unique palette applied to the 56 pixel rows at the bottom of the screen. The gradient border feels a little redundant and wasteful, but this panel does (almost) everything the Speccy version did, while looking slightly prettier by making better use of the SAM's graphical capabilities. The lives counter is a bit of a problem, though. The size of the heads is such that a maximum of three

TLC #1 - What Is 'The Lower Caverns'?

Long story short, The Lower Caverns is an update and expansion of the SAM Coupé conversion of Manic Miner , originally published by Revelation. It's set to be a coverdisk game with an issue of SAM Revival magazine, published by Quazar . Manic Miner , that most quintessential of platform games, has by now appeared on pretty much every system ever made, whether officially, as some sort of homebrew or at the very least running under a Spectrum emulator. It may not appear on so large a range of hardware as Doom , but it must surely be close (although I wouldn't be at all surprised if there's a version of Manic Miner that's playable on an emulator running within a Doom mod ). With few exceptions, each adaptation is the same, familiar game at its core, but takes advantage of a new platform's hardware to deliver something that is the very best version of Manic Miner each system could produce. ...And then there was the SAM Coupé version. The SAM Coupé got its version of

RR #1 - Revisiting Past Glories

While the majority of my graphic design/pixel art has been on the SAM Coupé, I started out on the ZX Spectrum, and wanted to get into game development from a very young age. At the very beginning, back in the early/mid 1980s, I used Pixel Pads , created by a Hertfordshire company named Computer Agencies Limited, which I'd acquired at a ZX Microfair. These were ideal for sketching out anything from a complete screen to individual sprite graphics, since they were designed with the Spectrum's 256x192 pixel screen in mind, with the 32x24 attribute block grid marked out using heavier lines. Most of the time, I used pencils but, over the years of using and reusing the pages of the pad, I ended up using felt-tip colouring pens on quite a lot of them, making them harder to reuse effectively in future. Eventually, however, I acquired The Artist II by Bo Jangeborg, which allowed my creativity to take flight in new ways. I wouldn't say I ever mastered The Artist II , nor OCP's Ar