Luma-Driven Graphics on the Commodore 64
Before reading on, I must emphasise that this article applies to PAL Commodore 64s only - I don't code for
NTSC systems because they can't reproduce the colour effects I use, they can't deliver the high speed visual work my interrupt game
engine produces and they represent a minority of the current retro scene; as far as I am concerned, they constitute a wholly different platform.
With that out of the way, 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 C64 COLOURS
As everyone and their mum knows, the Commodore 64's native palette comprises a miserly 16 colours of varying luminosity:
- #$00: BLACK (luminosity = 0%)
- #$01: WHITE (luminosity = 100%)
- #$02: CYAN
- #$03: RED
- #$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 ground-breaking use of the Variable Screen Placement (VSP) scrolling method, which enabled - for the first time in a gaming environment - a full-colour, full-screen, full-speed scrolling effect.
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 chroma noise 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 C64 COLOURS IN THE 21st 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 Colony 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 a toggled chequerboard technique.
That simply means a simple single-pixel based chequerboard whose alternating colours are swapped every frame by the game's raster interrupt engine; in Colony, this is the code that does it, executed once every screen refresh aka frame:
(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).
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, as you can see in Colony's HUD display in the short clip below; ensure the YouTube playback is in HD mode and the video at full screen size or you won't see it properly!
The lower part of the HUD just uses "vanilla" stippling / dithering, so you can compare the dynamic effect with its static counterpart (or look at the plane's shield meter shimmering to get the idea);
but the effect collapses if you pause the video, meaning it's a motion-based effect only.
Nevertheless, it has great potential for games, title screens, demos, etc., and so far it has enabled me to cook up a delicious dark purple by mixing red and blue and a bright blue shade by mixing cyan with sky blue, just to name a few very pleasing examples.
It 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 Colony:
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:
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!
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 Colony, 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:
- Luma-Driven Graphics, as discussed in detail above;
- Sprites (hardware and software) coloured predominantly black or white for contrast with the landscaping;
- Minimal use of Multi-Colour Mode, to ameliorate the blockiness it is synonymous with;
- Maximum use of hi-res graphics, for the same reason as the preceding point;
- The liberal use of multiplexed sprites and a more esoteric technique which I call toggle-plexing;
- Game environments which scroll smoothly, typically with parallaxing effects;
- Open vertical borders, to maximise screen real estate and create a sense of space.
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!
PS - SETTING UP VICE EMULATOR FOR CRT OUTPUT
Okay, you now know that using HDMI output from a C64 is not the way to see the non-standard colours; instead, you need a real PAL screen aka a normal TV.
But you want to see this on the VICE emulator too, only to find it is doing the "Fisher Price" colour output everyone else is using these days.
So you start to pull your hair out...
There is no need to denude your head of its follicles!
Just fire up VICE and take the following steps:
- Click on Settings.
- From the drop-down menu, select Video settings.
- Then select the VIC II Renderer tab.
- Finally, choose CRT emulation from the Render filter selector and BOOM!, now you can see the C64 output as it was intended.
If you liked this article and want to know when the next one is posted, kindly consider joining my 100% spam-free, nag-free Newsletter.
Anything you receive from me will be cool and interesting - especially if you're a C64 gamer or coder.
In the meantime, feel free to use the handy buttons on this page to share it on social media, if that's your thing!
Although I agree with most of what you have said in reference to PAL machines, the retro scene in the U.S. is hundreds of thousands of people just for the C64 - all using NTSC. :)
Jim, thanks for that comment and noted, but when it comes to selling games commercially, the European market is presently the major one.
I had actually planned to release an NTSC version of Colony, but as the game has developed I have found the timing with the Non-Maskable Interrupt game engine to be so tight as to make it difficult / impossible to fully replicate on US hardware, especially now that a vertical parallax effect within the horizontally scrolling parallaxed landscape is being added.
Also, the colour-mixing (or should I say, color-mixing) doesn't work on NTSC machines, meaning a whole design rework would be necessary; not a major problem in itself, but if the market doesn't warrant it, then it would be hard to justify.
Now, having said that, it may be possible to get some smooth, non-flickery new colours / colors on NTSC machines if you use the dynamically alternating chequerboard technique discussed in the article above but with the restriction that it can only be within luma pairs, which is something I hope to explore at some point.
My decision on the NTSC version of Colony is not yet final, but for now I am focussed on a PAL-only release.
Leave a Comment
Comments are moderated to prevent spam and emails are only required to filter basic spambots; such emails are neither harvested by me nor displayed on this website.