Skip to main content

TLC #2 - The Palette

Perhaps a little context, to start with.

The SAM Coupé has a gamut of 128 colours, effectively bookended with two super-dark sets of the ZX Spectrum's palette – one marginally brighter than the other – at the very start of the list (slots 0-15) and another two – in the lightest shades available – at the very end of the list (slots 112-127). In between, there are 6 groups of 16 shades each of blue-, red-, magenta-, green-, cyan- and yellow-biased colours. Colour 0 is black, colour 127 is the brightest white available, while pure greys are split between each end – three at the darker end, three at the lighter. Just for fun, Mel Croucher – founder of Automata and author of The User's Guide for the SAM – came up with names for each and every one of the colours.

Colours on the SAM are mixed with just four levels of Red, Green and Blue (2 bits per channel), with an optional BRIGHT bit (essentially a holdover from MODE 1's Spectrum compatibility) which can be applied across all three channels. Because of this, many of the available colours are remarkably similar, with the 48 colours in the green-cyan-yellow range coming out worst, followed by the 32 red-magentas, and then blue tending toward either purple or cyan across its group of 16.

Much as I love the SAM, I think its colour gamut is terrible*. For many years, I had mistakenly believed that the SAM had been intended to have 256 colours, generated by 8 levels of R/G/B, but that an error in its implementation of the BRIGHT bit had halved its range. As it turns out, I'd got it the wrong way round: it was originally planned to have just 64 colours, but due to a component change quite late in development, MGT found they were able to add the BRIGHT bit, which boosted the final tally to 128 colours. For most purposes, though, they might as well have not bothered, since many of the resultant colours end up flat, insipid, or practically indistinguishable from other nearby colours.

The SAM additionally has four screen modes designed for different purposes. MODE 1 is its Spectrum emulation mode, in which its 256x192px screen is broken up into the familiar 8x8px attribute blocks, colour clash and all. MODE 2 is functionally similar, but its attribute blocks are 8x1px, and doesn't suffer the speed penalty of MODE 1. MODE 3 is its 'productivity mode', in which the screen's horizontal resolution is doubled, giving 64 text columns rather than the standard 32. It's a mode which is very definitely not designed for games (though I'd really like to try, one of these days!), and the palette is reduced to just 4 slots. Finally, MODE 4 is the 'unrestricted' mode, where the full 256x192px screen opens up, and the 16 colours are available without the need to worry about attribute blocks. While it looks comparatively basic, the SAM version of Manic Miner is running in screen MODE 4, making it far easier to improve the look of the game. In theory, at least.

However, where most versions of Manic Miner have multi-frame, animated conveyor belts, someone on the SAM version's original development team determined that they could efficiently bypass the issue of the machine's relative lack of sprite-shifting horsepower by using 4 palette slots to give the impression of animation on static platform blocks by means of palette cycling. These 4 colours were also used to make the treasures sparkle and for the 'flashing' exits, once the player collects all of the treasures in each cavern. This left just 12 'active' colours for the sprites and scenery in each cavern, which seems incredibly restrictive at first. This active palette comprises white, a pure yellow, two shades of green, then an orange and a pink, either of which could be used to supplement two shades of red, and then three shades of a colour that functions as both blue and purple.

Initial default in-game palette:

Line interrupts had been utilised to grant the scoreboard a couple of additional shades of grey in place of the greens, but the colour cycling is technically still active, even though it's not used down there. Meanwhile, the title screen keeps the greens, but replaces the cycling group with more shades of grey. The weirdest difference is that white moves from slot 11 to slot 15, becoming a shade lighter along the way.

Title screen palette:

On the one hand, palette cycling is a clever trick to save processing power for the mobile hazards and give the SAM version its own unique spin on the flashing treasures... On the other hand, a quarter of the in-game palette had been sequestered. Technically, what's left is very close to the kind of optimised 16- or 12-colour palettes one can find at pixeljoint.com and lospec.com, but with a strong bias toward the warmer end of the spectrum.

Adding to the fun in the early stages of development, there were a couple of inconsistencies in the palette lists from cavern to cavern. One was fairly obvious – slot #0 would change to give some caverns a different background colour. Another – palette lists with 19 colours – was just a symptom of the way the game handles palette cycling.

More importantly, the colour applied to palette slot #4 showed up as one of two different shades of orange, depending on the cavern. It switched between Bright (colour 46) and not (colour 38, as used on the title screen). On screen, even under SimCoupe running on an HD monitor, orange 38 in small quantities is barely distinguishable from the 'pure' red in the game's palette, while orange 46 would blend almost perfectly with the pink in slot #6 unless there was another colour between them.

One of the questions for which we had no definitive answer during much of the early development time was which orange was the 'right' one to use, and neither offered a particularly subtle shift from the game's shade of yellow, but we ended up sticking with the brighter of the two since it played better with the rest of the palette.

The last change made to the default palette was to the two shades of green used (almost) consistently throughout the game. Initially, they were the darkest available shade of green (colour 4) in slot #1 and a brighter, solid green (colour 64) in slot #10. It had always nagged at me that these presented quite a harsh contrast with the game's yellow (colour 102), but the solution throughout most of development was to simply avoid using yellow-to-green gradients as much as possible. Toward the end of the process, I started playing with other shades of green, more or less on a whim, and certainly not in the expectation of solving any problems... Nevertheless, I did find that switching the darkest green in slot #1 with colour 12 (essentially the BRIGHT version of colour 4), and the lighter green in slot #10 with colour 74 (a lighter, more yellow shade) blended better with the yellow without overly compromising the overall impression of greenness.

Final default game palette:

In theory, it was possible to change several colours between caverns – something that had been done in a number of the SAM-specific levels, those additional to the original 20 – but there was a significant caveat attached. The original Miner Willy sprite already used 6 of the 12 active colours (making it one of the most colourful sprites in the game, even before I updated it), and these would ideally not change. On the upside, it didn't take too long to determine that there weren't many instances where palette changes would even be necessary so, for the earliest stages of development, I was content to carry on with the idea of keeping all but slot #0 fixed across every cavern.

So, in summary, Manic Miner operates in the SAM's equivalent of the 16-colour modes on the Atari ST and the Amiga, albeit at the lower resolution of the Spectrum. The available colours had been reduced by a quarter due to the 4 slots set aside for the palette cycling used to 'animate' conveyor belts, as well as making treasures and exits flash. Additionally, one palette slot could be used to change a cavern's background colour, leaving 11 colours common to all, six of which were used on the player sprite. Updating and improving the graphics was going to be as much a technical challenge as an artistic one.

While I was, until a couple of years ago, very much out of practice in pixel art, I've spent much of the intervening time paying close attention to how graphics were designed for machines like the NES, GameBoy Color, Master System and MSX. The latter, in particular, has screen modes nigh-identical to SAM's Modes 2 and 4, but 20 pixels taller. The main advantage some of these systems tend to have is a palette-per-object or palette-per-layer as opposed to a palette-per-screen, but I've been able to adapt NES and MSX graphics to the SAM easily enough, and feel that it has been quite instructive to do so. Additionally, more recently, I've spent some time experimenting in downgrading graphics from various arcade games to a rigid 16-colour palette on the SAM, which has further emphasised the importance of palette optimisation.

Fixed-palette pixel art seems to have become popular again in recent years. Perhaps it's a form of rebellion against the push for, hyper-realistic 3D graphics on high-definition LCD screens in the spheres of contemporary PC and console gaming, or perhaps it's the natural result of strong nostalgic feelings towards older games, gaming systems and CRTs as gamers from the 70s, 80s and 90s get older. These days, there are plenty of resources available for creating pixel art, not least dedicated sprite and tile design software like Aseprite, and art packages like Multipaint. There are even websites offering a selection of pre-defined limited-colour palettes, many of which can be approximated on the SAM. All of these things have, I think, contributed to improvements demonstrated with my work on The Lower Caverns, so I'm confident that the end result will be well-received.


* NB: This should perhaps be read in the sense of a bad workman blaming his tools, since I would happily admit that most of my own early work on the SAM wasn't great. I had come from a background of designing largely monochrome graphics on the Spectrum, so at least 90% of the SCREEN$ I put together in those days were effectively monochrome 'outlines' with block fills of a single colour in fully-enclosed areas, and very little consideration of anti-aliasing.

Additionally, I used to have a really hard time setting up a decent 16-colour palette, because I became fixated on having at least three shades of every colour used. It never occurred to me, back in my youth, that the presence of more colours could be implied by clever usage of 'mid-ground' shades that were either wholly neutral or sufficiently similar to at least two different colours to pass for another shade of either. Worse still, many of my earlier efforts barely changed the palette from the SAM's default.


Comments

Popular posts from this blog

WH #5 - It's Not A Bug, It's A Feature

Continuing on the subject of things I really dislike when creating pixel art, we come to the things creeping and crawling around in Westen House , presenting the action-oriented  aspect of the game's challenge: In theory , a group of two-frame animations is nothing special and, in fact, for three out of these four creatures, it's no problem at all. The rats work well enough, the bats look pretty cute, and the blobs are kinda funny. The spiders - at least, I'm assuming that's what they're supposed to be - are pretty confusing, though. The bobbing cephalothorax on a static abdomen and legs that basically just go up and down get rather lost, because they're monochrome and only a single pixel wide, with weird angles in their joints. I realise it's very difficult to animate something that size - particularly something as complex as a spider - but it's hard to recolour something if you don't understand what yo...

WH #3 - Heroes and Villains

While much of Westen House on the MSX runs in that machine's equivalent of MODE 2 on the SAM Coupé, using MODE 2 in the SAM conversion would result in less colourful sprites and significant attribute clash, because the SAM lacks the MSX's ability to overlay sprites, effectively on a dedicated layer, separate from the background and entirely without clash. It'd look better than an equivalent conversion to the ZX Spectrum, but probably not by much . From left to right, we have Professor Edward Kelvin (the player character), Arthur Holmwood, Dr. John Seward and Lucy Westen: The above appear to be single sprites, but they are actually several different sprites overlaid on each other to give the impression of individual, multi-colour sprites. It's similar to a trick I've seen used on the Commodore 64 (not least in Reckless Rufus ) where high-colour mode is used for the base sprites and the tiles, but then high resolution mode is used as an overlay...

TLC #4 - Willy or Won't-y?

In the original version of Manic Miner for the SAM Coupé, the Miner Willy sprite has only 4 frames of animation, just like the Spectrum version. Of the later-generation versions of Manic Miner , those that did more than just duplicate the Spectrum graphics without attribute clash upgraded the player sprite to a whopping 8 frames, allowing for a smoother, more convincing swing of his arms, both forward and back. I didn't initially plan on completely overhauling how the player sprite worked, and we were perhaps two months into the project before I even started dabbling. To my mind, improving the SAM version required increasing the number of animation frames, because my improvements to the sprite made it a little bit too obvious that his arms only moved in one direction, then magically popped back to their opposite positions. But my primary concern from the start was the overall look of the sprite and its poor usage of MODE 4. On the existing sprite, Willy's headgear is all...