What better way to start off my new blog, than with a first post about my first concept work on NES compliant graphics? Mild warning: this post is a confused blend of personal retrospective and ”i-guess-we-can-call-it-an-inspirational/tutorial?” and i’m not quite sure who i’m writing for here beside myself. If you’re new to the technical side of the NES or 8-bit graphics in general, there’s a glossary at the bottom of this article that’s hopefully of some help.
Here it is – a background screen:
Telling without text
I’ve always liked visual story telling, and this was kind of half-consciously drawn to be such a story element. Retrospectively thinking, the idea is this: Rather than having a text tell the story or background, place meaning-carrying objects in relation to each other in order to create some narrative tension. Leave it to the onlooker to fill in the gaps on what the scene (or whole game background is about).
It could perhaps come across as ”Here’s a gothic romance scenery: something in decline, crumbling, left in disarray. What does it mean? -meanwhile, over there, there is some foreboding activity going on in a lone keep. Who- or whatever’s in that castle, might be the answer to the questions posed by the foreground.” I do not know that’s what would cross every mind, but i entrust the hypothetical player/s to come up with something that works for them. The point is that the imagination of the audience is a more dynamic tool than hard outright statements from the author. I also wanted it to be used by the player as an optional and implied roadmap or beacon. ”Here am i, and there is where i want to/have to go”. It’s the classic castlevania trick. Or the Lupin III trick, i suppose.
NES graphics does the gaps, you do the filling in
Black is an often facilitated background colour on NES/famicom titles. While it is a good resting colour, there’s more to it: shadows and darks are yet again a technique for letting the onlooker fill in the gaps. This is an effective remedy for the limited memory of the PPU (picture processing unit) to make a small set of graphical components seem like more. A contour can be enough for the mind to create meaningful content to the surface. The amount of detail on or close to that contour can help provide a sense of depth.
Getting more metatiles out of less actual assets
Placing the same 8×8 graphical tiles in different positionwise relations to each other on the nametable is another way of cramming out more from the same small set, but you don’t see that too much in the commercial cycle of NES games, mostly – i would assume – because data storage in the form of EPROM chips were expensive at the time, so you had to do viable business choices. Post-market/hobbyist NES development doesn’t suffer from this issue in the same way, so at least there’s a potential for more varied levels, story screens and what not today.
Colour and palette priorities
This screen is, perhaps suprisingly, using up all four of the NES’ background palette sets. This is so that the directional light could be more nuanced, and so the so-called attribute grid could be a bit broken up, at the expense of warm colours. They could possibly be compensated for in the sprite layer, which has its own four palette sets, but as it is now, this screen is background only.
A dubious choice of colours is the mountain reflection in the lake. Depending on PAL or NTSC (never the same colour) region of your console and TV the contrast and brightness of the latter (or laptop, phone, etc), it can look better, or much worse, as shown in this NTSC simulation, tool courtesy of NES veteran blargg. This is because it is only slightly differentiated in hue, not brightness, from the rest of the water body. Due to the indexed colour nature of how NES bitmaps, just changing the colour to something else also affects every other area using the same palette. A stylistic redesign on tile-level would be necessary if i wanted to change this to something more robust at some point.
Vertical lines, borders and hardware
Moreover, the thin blue vertical lines in the foreground gets a very noticable bashing on real hardware because of the way composite video works. They basically get a sawtooth like pattern. My first actual hardware tests were done some time after i began doing NES graphics. Several post-hardware test observations can be made. One is how fields of hue-axis neighbors on the palette get a thin dark dotted line between them.
This first concept screen stuck in the back of my head, and I hope to return to this specific concept one day in the form of actual game development when the time comes. For now, other projects are in the pipeline. More on that in a while…
If you took the time to read this far, what did you think of the direction this first post is going? In what direction would you like me to go?
If you’re new to development for the NES, here’s a short glossary to help the readability of the article.
Tile; sometimes called character or pattern (just like the in the textile and printing industry): an 8×8 px portion of graphics that can be held in the pattern table of the PPU. These are repeated on the nametable, which is essentially what you see on screen.
Nametable; a bitmap in PPU memory that tell what tiles go where on the screen. A NES program normally makes use of 2 or sometimes 4 screens’ worth of nametables simultaneously, depending on mapper/cardridge PCB.
PPU: Picture processing unit. Like a GPU, but with a hard defined set of tasks. When processing graphics on the NES, you almost always do it via the PPU:s hardware registers. Some unusual/special tasks, like shearing, must be done in software.
EPROM; stands for erasable programmable read only memory. It’s the physical storage chips in a NES where you store program and assets. A wipe is done by exposing the silicon to strong UV light for some time through the quartz window on the chip (normally masked with tape). A variant is the EEPROM (meaning electrically erasable). More versatile, cheap and quick-to-reprogram alternatives are available today, like flash ROMs.
Post Script additions
Rahsennor, who’s the coder of wrecking balls, sent me this new NTSC emulation of the screen. I currently only have PAL hardware for testing graphics. If anybody can chime in on the accuracy of this emulation, that’d be handy for future concepts and projects!