Luma-Driven Graphics on the C64

Introduction

I would like to firstly say that, to avert the accusation of being somewhat pretentious in naming my design philosophy Next Generation Graphics, I had to find a more palatable term to emphasise the dichotomy between old school styles on the Commodore 64 and my own.

Hence I ran with as literal a description as I could think of: Luma-Driven Graphics, meaning that my graphics design style follows a distinctive, logical order based on the methodologies I use to generate non-standard colours on PAL C64s.

A quick recap on Commodore 64 colours

As everyone and their mama knows, the Commodore 64's native palette comprises a miserly 16 colours of varying luminosity:

• #$00: BLACK (luminosity = 0%)
• #$01: WHITE (luminosity = 100%)
• #$02: RED
• #$03: CYAN
• #$04: PURPLE
• #$05: GREEN
• #$06: BLUE
• #$07: YELLOW
• #$08: ORANGE
• #$09: BROWN
• #$0A: PINK (aka "LIGHT RED")
• #$0B: DARK GREY
• #$0C: MID GREY
• #$0D: LIGHT GREEN
• #$0E: SKY BLUE (aka "LIGHT BLUE")
• #$0F: LIGHT GREY

Originally, the colours were assigned lumas in the clusters shown below:

Thus there are (or rather, were) five distinct groups in the original C64 palette, with a hefty six equi-bright hues occupying the mid-luma cluster, balanced out with four pastels (yellow, light green, cyan and light grey) towards the white end of the old VIC-II spectrum and four equally dark shades (red, blue, brown and dark grey) on the black end.

I believe Archer MacLean consciously designed the title page for his seminal C64 game, Dropzone, to avail of the old lumas as the basis of the colour cycling effect in the game's logo.

The result was subtle and, for me, very cool as it alternated between the four equally luminous colours of yellow, light green, cyan and grey:

But the effect was lost when Commodore tweaked the VIC-II palette to create a less homogeneous range of new lumas, leading to odd-looking rolling bars of colour across the Dropzone logo, leaving players of the game on the newer machines to wonder what on earth MacLean was thinking of when he created the effect:

As the Dropzone title page logo highlights, the new C64 palette separated the colour groups from five to nine luma clusters, meaning that yellow and light green forked into their own luma pair and left cyan and light grey to form their own distinct luma pair, fouling up the original Dropzone logo effect in the process.

The new lumas don't constitute a total disaster for games designed before they came along; in fact, very few early C64 graphicians seem to have bothered designing anything with luma-driven considerations.

But they abide as an important factor for my own design philosophy because of my penchant for non-standard colours, as I shall now expand upon.

Non-standard colours circa 1993

In 1993, Mayhem in Monsterland was released to widespread critical and consumer acclaim, scoring an unprecedented 100% rating (albeit controversially) in the abortive Commodore Format magazine.

The game was stunning, transcending the gap between the cutting edge technical advances of the demo scene and the wash-rinse-repeat stagnation of the slowly dying commercial gaming world.

From a technical perspective, Mayhem received its most lavish plaudits for its lavish use of the Variable Screen Placement (VSP) scrolling method, which enabled a full-colour, full-screen, full-speed scrolling effect with minimal CPU time outlay.

However, I was personally more intrigued by its other much-vaunted technical innovation:

The use of non-standard colours.

The developers themselves (the Rowlands brothers, aka Apex) made reference to this during their development diary, which was serialised in the above-mentioned Commodore Format magazine, which you can read about in-depth in this PDF compilation of the diary entries.

Essentially, their method was to combine two colours within the same luma cluster in such a way as to artificially synthesise a new intermediate hue.

They did this using the Alternate Line Method (ALM), yielding results such as the green + mid grey shade depicted below:

ALM simply means filling even horizontal lines with any Colour A within any given luma cluster and the odd lines with any Colour B within the same cluster.

So, we could generate a new shade of green by doing what the Rowlands boys did in the image above and alternating green (#$05) with mid grey (#$0C).

Or, as another example, we could take yellow (#$07) and alternate it with light green (#$0D) to make a nice, seamless blend between the two colours.

An additional quirk of this PAL-only effect is that the resultant non-standard hue will be somewhat different if you swap the colours on the odd lines with those on the even lines; this is due to a slight bias towards the colour on the top line ("Colour A" in the explanation of the method given above) in any such ALM block.

Consequently, you will have to compensate for this if you perform any kind of vertical movement on the ALM-based non-standard colour.

But remember, all of this only works for colours residing within the same luma cluster (and it assumes you are using "proper" PAL television output or CRT emulation on VICE); violate the luma cluster rule and you'll get visible horizontal lines.

And since it only works for colours within the same luma cluster, it means Mayhem's green + mid grey bushes will look non-blended and a little stripey using C64s with the new lumas, as mid grey and green belong to two distinct clusters in the later machines, not the same luma cluster as per the old ones Mayhem was apparently designed for.

The implication is therefore plain:

Luma-driven graphics today should be designed for the new lumas, making them backwards compatible with the old luma machines, whereas colour schemes devised for the old lumas will inevitably fall flat when executed on new luma C64s (I illustrate this point with screenshots later in this article).

That raises the question as to the full number of colours now possible on the Commodore 64; Ilkka Sjöstedt, in his in-depth article on VIC-II lumas, calculates a theoretical possible 70 colour combinations using this method with the old lumas, but only 30 with the newer machines.

Now, I don't know about you, but 30 shades isn't quite enough; can't we squeeze some more in?

New Commodore 64 colours in the 21^st Century

Since there is no rule that says we can only achieve non-standard colours on the Commodore 64 using ALM, maybe it's time to revisit the whole theory with a view to ripping received wisdom on the matter to shreds!

I'm not going to propose toggling colours every other frame, which was another effect the Rowlands brothers first used in Creatures, if memory serves me correctly; it's okay for small objects such as sprites, but produces a discernible and rather annoying flashing effect over larger spaces.

Instead, I am revisiting old-school stippling to see how it meshes with same-cluster luma hues.

What I am actually proposing here is to tweak ALM so that the horizontal lines are broken into one pixel dots or two pixel dashes, creating little chequerboards made up of two colours within any given luma cluster, or, since we're designing for the lowest common denominator VIC-II chips, that would be two colours within any given luma pair.

As long as you stick to colours within luma pairs (e.g. cyan + light grey or sky blue + mid grey), you can produce subtler intermediate hues that still look as smooth as any of the their native constituent parts.

Check out the blended sky or the grass in the image of Parallaxian below to see what I mean:

Some of it uses ALM, some of it uses chequered blending and some of it uses an additional innovation in the form of an alternating frame toggling chequerboard technique I call the Dynamic Chequerboard Method (DCM).

That simply means a simple single-pixel based chequerboard whose alternating colours are swapped every frame by the game's raster interrupt engine; in Parallaxian, this is the code that does it, executed once every screen refresh aka frame:

LDY $7DB0
LDX $7DB0+1
STY $7DB0+1
STY $7DB0+3
STY $7DB0+5
STY $7DB0+7
STX $7DB0
STX $7DB0+2
STX $7DB0+4
STX $7DB0+6

(In this instance, $7DB0 is just the first byte in the user-defined graphics character that this dynamic effect is being run on; note the absence of a loop - this is a micro-example of so-called speed code used to save cycle time in the raster interrupt).

It transpires that this is a very powerful technique, because it enables us to do another special colour trick: blending two colours from different luma pairs to create, for example, the C64's first smooth shade of dark green.

This kind of non-standard colour generation does have some limitations however: nothing quite works with black and, as a general maxim, the more widely disparate the two constituent native hues are, the less compelling the resultant effect is.

Compatibility between old and new lumas

As you can now see, I have used a variety of techniques, well-known and somewhat less so, to wring non-standard colours out of PAL C64s.

And now that I have explained my various methods, I want to return to the importance - stated earlier - of designing luma-driven graphics for new C64 lumas as opposed to old.

Look at the example below, once again experimenting with Parallaxian:

The colours provide a sky redolent of dawn or dusk, but the orange highlights in the forested foothills look out of place; on the plus side, orange and green have been successfully blended in the score panel area at the bottom of the screen - assuming that particular combination is your thing!

Now let's have another gander at it in the new lumas:

Ouch!

That's not going to scan with players of the game...

If nothing else, however, it does - if you are viewing it on a desktop or sensibly sized screen and not a smartphone - reveal my colour-blending methodologies, plus it highlights why we must impose a new-lumas-first design policy.

Accordingly, let's fire it up once again with the actual, close-to-production new-luma-first colour scheme:

That's better because the chroma noise effect ensures no visible pixelation.

But will it work on old luma machines?

Only one way to find out!

Hooray!

Now we have a colour scheme designed for new lumas that works well for old lumas also.

Sure, the orange highlighting on the forested foothills are still a little off, but it's more than acceptable in terms of its impact (or lack thereof) on the overall look.

Completing a design style

With the colour philosophy settled, I would like to incorporate it into a broader, holistic design style with a distinctive approach to sprite design also.

With all the luma-driven shenanigans going on with the game environment, and with my passionate dislike of hard-to-see sprites, it was a natural extrapolation to strictly adhere to sprite colours dominated by the two polemics, black and white.

This rule ensures that in-game sprites are always visible against the various intermediate hues in the background.

In the case of Parallaxian, the player's sprite and the adversaries are predominantly black, with lesser highlighting in white and darker-end colours; lasers and other "electric" forms of artillery are white.

Expanding on that within the following summary of it all, my C64 graphics design philosophy consists of:

1. Luma-Driven Graphics, as discussed in detail above;
2. Sprites (hardware and software) coloured predominantly black or white for contrast with the landscaping;
3. Minimal use of Multi-Colour Mode, to ameliorate the blockiness it is synonymous with;
4. Maximum use of hi-res graphics, for the same reason as the preceding point;
5. The liberal use of multiplexed sprites and a more esoteric technique which I call toggle-plexing;
6. Game environments which scroll smoothly, typically with parallaxing effects;
7. Open vertical borders, to maximise screen real estate and create a sense of space.

Conclusion

I know much of the above will elicit frowns from some old school graphicians and perhaps draw ire from the present group of Commodore 64 sceners who can't bear to upload a clip or take a screenshot without removing all trace of CRT chroma noise effects.

However, I like this design approach because it massively expands the C64 palette, imparts freshness to game design and inspires me to try things that hitherto really belonged on a 16-bit machine.

Now don't get me wrong.

This design methodology does not "insist upon itself".

If you like the bright and eye-burning CRT-free style, more power to you; it's just my games won't look right if you run them with your video output in that mode.

So if you can take all of that in the way it is intended, maybe you will one day find that I have been onto something special with this luma-driven graphics approach; at least, that's my hope!