My lizard is the Lizard of Pixels
I've covered a few graphical topics in NES development already, like tiles, sprites, and scrolling, but I neglected a very fundamental component of computer graphics: making images out of a grid of tiny dots of colour, also known as pixels.
A modern high definition display might have a million pixels, or more, but the NES picture only has about 60 thousand. At this resolution each dot makes a more significant individual contribution to the image.
As an demonstration of how this works, I have attempted to translate this painting by J. C. Leyendecker (the cover of The Saturday Evening Post, June 3, 1905) into pixel sketches at various limited resolutions. I am not just reducing the number of pixels in the image, but also the number of colours. A limited palette is usually a relevant constraint with pixel art, though on some systems it doesn't have to be.
On the far right is the original image at 256 x 256 pixels. In the middle is the same reduced to 128 x 128 in an automated way. On the left is the version I redrew for 128 x 128.
The most immediate difference here is the limited palette of colours. I chose these colours from a set that is similar to what's available on an NES, but the immediate problem is that I don't have a lot of different brightness levels in this palette, so I felt that some things that were too close in hue, like the man's skin and suit, should have their colours adapted to keep them visually distinct. So, the suit becomes purple, the background becomes blue. This also makes it harder to capture small details of shading, like all the scales on the woman's costume. At this size, smaller features of the faces have just begun to disappear, but much remains intact and recognizable.
The faces have lost most of their features. I dropped the grey colour I was using to give shape to her teeth and claws because there wasn't really enough room to make use of it.
A lot of details have been reduced to single dots. Since there are not enough pixels on his face to really do much shading, I've reclaimed those yellow colours for the man's suit. The little goose in the top right corner is gone. I struggled with decisions about how much light green to use on the woman's costume; the dots have become a little noisy and disconnected, and the complicated shape of the costume's edge is dissolving.
There really wasn't room for any shading at all here, just shapes in a single colour. His tie has become a single dot, and I kept a few pixels of white for the shirt; this seems a lot more than was showing in the original but maybe we can imagine he has a few buttons undone for the sake of having this extra feature. The proportions of everything are a bit abstracted. Note also how the automatically reduced version in the middle has barely any recognizable detail left, despite being completely unconstrained for colour.
We could keep going, but I hope by this point these sketches have made the basic problems of pixel art clear.
While I did say that pixels are fundamental to computer graphics, there are other ways to make an image with a computer too. Many earlier graphical displays use vector graphics that built an image by tracing lines across a CRT screen. This was well suited for the continuously changing shapes of 3D graphics simulations, like in the first Star Wars Arcade Game, but it was difficult to make any solid filled shapes with this method.
While most modern displays do work with a grid of pixels, as the resolution has become finer and finer the impact of that pixelization has diminished, and eventually it wouldn't matter to the viewer if the image was displayed in some other way. A lot of things, including fonts and most 3D graphics, are largely built from curves and lines and triangles, and will get converted to pixels at whatever resolution is available. The actual image you're trying to view is something else, the pixels are just the medium being used to deliver the image.
Though the word pixel came into use in the age of computers, many of the techniques of pixel art apply in other much older mediums.
Consider these 3rd century Gallo-Roman mosaics made of small coloured tiles (source: 1, 2). They may not have to deal with a regularly spaced grid, but they still have the problem of granularity of detail. See how the leopard is speckled with single-tile spots, or how the boar's individual teeth are spaced and counted by the resolution of the tiles: it has as many teeth as could fit as separated pixels. Compare those teeth with this pixel dinosaur created by Jim Sachs.
Woven tapestry very much deals with a regularly spaced grid, and a limited palette of colours, though the resolution of pictures in tapestry is typically quite large compared to most pixel art. This fragment of The Mystic Capture of the Unicorn (source) shows something like pixellation in the fine lines and details, especially the woman's hair. Note the alternating lines of colour in the leaves, used to simulate more gradiations of colour than it has in its palette. This is not unlike some of the dithering techniques seen in this image from Jesus II (PC-88, Enix, 1991).
I found this cross-stitched house in my Great Aunt's kitchen, and I was immediately reminded of a similar scene from Little Computer People (Atari ST, Activision, 1986). Is cross-stitching pixel art with fuzzy X shaped pixels?
I've talked about the limited set of colours the NES has to work with in a previous update, so I won't go into too much detail here, but the basic palette is approximated below. There is a moderately good selection of hues, and a somewhat poor selection of brightness. Not the worst of its time, but still feels pretty limited to work with.
The Super NES had several improvements to its graphics hardware over the NES, but even if it had just been more colours, that alone makes a huge difference. Because the pixel resolution was not actually increased for the SNES, normally, there are cases where it's easy to compare the two on palette alone.
There is an interesting technique that I've seen in modern art for the ZX spectrum. It had an even more limited palette than the NES, with only two brightness selections per hue. Looking at this fan-made title screen for Golden Axe II by Oleg Origin (ZX Spectrum, 2016) With more hues than intensity available, the artist seems to substitute for light and dark with a chromatic shift. It creates a slightly surreal rainbow colouration, but perceptually it really does seem to give the intended feeling of brightness. I'm reminded a little of the use of colour by Futurist Umberto Boccioni (source).
Besides their colour and resolution, pixels come in different varieties of shape as well. Most modern displays use a square grid, where every pixel has the same height as its width. This is quite natural, and a very sensible shape for a pixel, but 30 years ago it was actually quite uncommon.
The internal resolution of the NES is a 256 x 240 pixel image, though there is some padding at the sides, and cropping at the top and bottom. Between these factors and the 4:3 rectangular shape of the standard television screen of the time, we seem to get an official pixel aspect ratio (PAR) of about 8:7. This means that an NES pixel is ~14% wider than it is tall. This is a small difference, but emulators often favour clean pixel scaling instead of stretching, which results in an image that is a little too narrow. Something circular, like Dr. Mario's magnifying glass, ends up a bit oval without the correct PAR:
The image above shows the correct proportions for the picture for NTSC televisions (used in North America and Japan), but there was a different, wider, pixel aspect ratio in PAL regions too. Despite this I'm not aware of any NES games that had their graphics adjusted for this changed width when ported to PAL. Then again, on modern 16:9 television displays, a lot of people seem to play with their NES picture stretched way out of proportion anyway...
Square pixels are very convenient for a lot of reasons (e.g. rotated images retain their shape without changing their pixel scale), and it is almost taken for granted with modern screens. However, with older television technology the horizontal and vertical aspects of the picture were accomplished by very different mechanisms, so there were a lot of good reasons to use different sizes for them.
The tradeoff between cleanly scaled square pixels and the proper aspect ratio is a very pervasive problem when emulating older games. The popular DOS VGA 320x200 resolution had a 4:5 PAR, but it's really hard to find images that aren't vertically squashed down to a square PAR. (I'm as guilty as anyone else of using cleanly upscaled square pixels instead of their original aspect ratio. Even across this document about pixels, for most examples I thought the even scaling of square pixels was better for showing the pixel nature of the art.)
There's a few other ways to arrange pixels, too, like the hexagonal grid (hexels?) used by the popular Lite-Brite toy. (This was actually used as an ad-hoc pixel art tool during the development of Ms. PacMan.)
The video signal itself alters the appearance of pixels as well. As the NTSC NES generates the picture, it doesn't have quite enough bandwidth to properly encode the colour of individual pixels. Groups of pixels that are the same colour will appear as they should, but pixels that are isolated or at the edge of a shape will have colour errors.
These colour errors mostly take the form of a diagonal pattern that repeats every 3 pixels. In the picture above, you can see these diagonal patterns especially in the dark blue area of the wizard's robe where a checkerboard pattern of alternating black and blue pixels was used by the artist. It is common to see "shimmering" artifacts in NES games while scrolling, as the error pattern stays in place while the underlying pixels move against them.
These colour corruption artifacts are well understood, and there's an NTSC simulation library by Blargg that has become the standard implementation of it used by many emulators. On the other hand, the European version of the NES used the PAL standard rather than NTSC, which had a different affect on the picture. PAL in general was known for being a bit clearer image than NTSC. Unfortunately, the PAL signal is not easily emulated by any NES emulator I know of, currently, but I think this will eventually be available.
At the end of it all there's also a television screen that has to display this. This has a bunch of effects on colour, sharpness, et cetera, as well as colour display methods like the shadow mask or aperture grille. I don't want to go into TVs too much, but there's a whole dimension here of additional factors that affect the image you see.
When I made Lizard, I designed it with all of these things in mind. I reviewed all the art in both the widened NES PAR, as well as square pixels, and I tried to make sure it looked correct either way. I also made sure to review how it looked through the NTSC signal process, because it's easy to accidentally make details that get badly corrupted by it. For example: this is why the text in Lizard uses a thick font with vertical strokes that are 2 pixels wide. (Look at the number 8 in the timer of the Castlevania animation above to see what happens when the strokes get thin.)
So with all that described above, a bit about what pixels are and the way they work, what did that mean for Lizard?
Lizard's character is intentionally on the smallish side for an NES game. This was partly to make the world bigger in comparison, and is related to how I used 8x8 pixel tiles to build that world instead of the more common 16x16. The other part of this, though, is that I really love the ambiguity that is caused by trying to fit details into such a tiny resolution.
Here's an example of that kind of ambiguity, comparing a sprite from Zelda II (NES, Nintendo, 1987) with artwork produced for a guide book. The guide's art is clearly based on this sprite, but just as clearly had a very wrong impression of what it depicted. Is it a more fair mistake if we consider the artist squinting at the NTSC corrupted version on their blurry television screen? The ability for low resolution pixel art to be read in different ways is very interesting to me.
Another aspect that went along with this small, low resolution was an embracement of noise. Noise generally refers to the effect of randomness, or in pixel art: pixels that may appear "randomly", out of place, without justification. This tends to come from miniscule details that reduce to a single pixel, maybe too small to represent a specific feature, but enough to give an impression; little dots and sparkles that straddle the threshold of meaning. I know many pixel artists who eschew noisiness as a general rule, but it's an area of pixel art that strongly interests me. I wanted to explore that narrow edge that divides tiny pixel details from random noise.
I didn't play Faxanadu (NES, Hudson Soft, 1987) until Lizard was well underway, but when I saw its gritty speckled world it was like meeting a new friend. Aesthetically this seemed very similar to my goals for Lizard's art. On the opposite end of the spectrum, compare the excellently clean, cartoon sprites of Boku Dracula-Kun (Famicom, Konami, 1990).
Across the environment, I made use of "noise" on a larger scale too. In most places where I had to fill in a large area with tiles, I tried to use a randomized set of tiles across that space. The goal here is to give it a solid looking texture, but trying to reduce the feeling of a "grid" that often comes with tiles, and especially to break up repeating patterns. I'm not sure if this is aesthetically appealing to everyone, but it seemed to produce an "organic" look to these areas that I was satisfied with.
I hope this is not too much of a spoiler at this point, but: Lizard takes place on both sides of a page in a book. There is very little three dimensional depth in Lizard's environments, and it intentionally expresses this aspect of the setting. Lizard's world is flat. (I made a deliberate exception to this for the River Zone, however.)
Though the flat world was part of my concept for it, this was also supposed to help keep the budget for graphics tiles low by mostly not having to keep extra tiles for things in the background, or 3D extensions of platforms into the background. The original plan was to fit the entire game into half the data size that it eventually filled, and the tile set was designed to be a little bit parsimonious. However, when I did double the memory budget, I wanted the game to remain faithful to the look I had established for the original demo, so even though I added a lot of new graphics data to the finished version, I did not allow myself to redesign the original tilesets.
On a final visual note, I've produced a large image collecting together all of Lizard's sprites. This is everything in the game that wasn't part of the background layer. You may notice that most of a giant frog is absent, because it was too large for the sprite hardware to handle. Its hands are freely moving sprites, but the head and body had to be more stationary.
Actually, the image above came from a set of Lizard wallpapers I had to produce for Steam trading cards, but there are some unfortunate formatting requirements that got imposed on those. If anyone is interested in the less repressed forms of those background images, they are available here:
Still to Come
So the game has been out for a while now, what should you still expect? I have two or three more planned updates about Lizard's development. There will also be a source code release for those who would like to dissect Lizard, and I'm currently working on slightly wider language support. Right now the game is available in English and French, but I still hope that other languages will be possible in the future.