Project ”obituary”: T-rex Rider

I was going to do a blog update about some few design points on this project, but unfortunately, the programmer recently had to cancel further development due to personal reasons. Well, who knows what the future might hold. I do hope this project will get resurrected at some point in some form, because the NES needs a game about a lonesome cowboy having a terrible idea.

Anyway, i learned a few things in the process and writing things down helps solidify those experiences. I might aswell share them – here’s something to listen at while reading/looking at the rest:



4x zoom






I’m fine with how the sprite animation ended up at this point, but the head could still need some position-domain alterations to make it seem more alive, as pointed out to me by the very skilled nes graphics maker M-tee.

The main thing i want to point out with the sprite animation is the technique for making teeth seem sharp. With a resolution and sprite size like this, you can only get square pixel blocks for teeth. But if the head is at an angle so that they line up diagonally, you can turn this downside of resolution into a feature. The edges of the pixels now become the pointy ends of the teeth! Admittedly, this effect gets distorted by some on a regular tv. You’d want a bright colour like white, off-white or pastell to keep them in line as much as possible on NTSC/PAL.

It was hand-drawn frame for frame (16 frames in total) and is run at a constant 10fps (for now). Hand-drawing is tedious but does provide a more organic feel compared to layer compositing (the other main mode of raster graphics animation).

Sprite design
The t-rex has a highlighted outline (rather than a dark one) partly out of style (nonrealism, cheery cartoonism), but also because it’s an ”avoid everything coming at you” type of game. Boundaries for hits need to be clear. What you see is what you hit.

Soundtrack notes
The music was written with the following technical specs in mind: Since the game is NROM, there’s no irq to help with scanline counting. Since the game was meant to have some scroll splits for parallax effects, even timing was important. That meant the music engine shouldn’t produce workload spikes and work with a constant amount of cycles, lest the scrolling breaks. Luckily, pubby on nesdev had released such a music driver under MIT license. It comes with severe limitations. As such, this song doesn’t make use of FamiTrackers’ volume channel, nor any effects. The mixing is written into the properties of the  so-called instruments.  All in all, it takes 2,5kB of ROM space, but after conversion from FT to pubby’s format, i assume it would be somewhat larger.

Playfield layout
While this isn’t to be taken as the final set of graphics, there’s one thing to note.
By limiting the height of the play field and keeping graphics simple at the top and bottom, you get a more widescreen-like field of play. This helps guiding the player’s eye towards what is important: the mid-right, where enemies and obstacles will appear as you run continously to the right.

Many thanks to El Seyf who wrote the code; including an ingame animation tester.

The code has been made open source, and can be found here. Especially the macros might be useful for other NES projects.

Making worlds alien

Here’s a concept screen for an untitled NES collaboration slowly taking shape.


I tried thinking material this time. I followed a certain order to work out the details.

  1.  First, define what ground looks like.
  2. Put that in a context. Ok, so we’re in some sort of ravine or valley. I also added a contrasting look to the distant background to foreshadow another set, but that’s beside the point.
  3. Establish what life forms would thrive there.
    I went with two main vegetation strategies: something flourescent, moldy, creeping (thrives in the accumulated moisture of the shadows, may fit a symbiotic nische), and something striving to reach up, with a sensory organ (the eye-like thing) at its extreme. Those are meant to be animated and follow the direction of the closest moving object.
  4. Last, introduce alien-made constructs. Since we’re dealing with a moist environment, piping seems fine. Maybe it’s some kind of managed mold farm? Or a drain system? A structural skeleton? It’s really up to the player*.

alienplanetTile/character usage-wise, it’s acceptably efficient (by designing tiles to be combinable in different ways on the meta-tile level), currently using up 38% of the background tile page. There’s plenty of room for animations, bg-based enemies, or a whole other set loaded at the same time.

alienplane3tFor comparison, here’s a snapshot from somewhere halfway in the set-building process. It is preferrably uncrowded. Levels shouldn’t use every asset every screen, lest you oversaturate the experience.

I’m interested in critique. If you have any, please comment.

*The last step makes a point. For it to feel alien or strange, let it be vague. Example: What’s so great about Alien, the movie? You don’t get told what’s what. It hints at a much larger, wondrous, and horrific universe with schemes and designs beyond the human scope. What’s not so great about alien 3, resurrection, prometheus and onwards, apart from their individual failings? They do their best (worst) to serve the audience a digestible explanation of everything (a substitution for a solid plot), which sucks the life out of the fantasy.

1st year of doing NES gfx, 1st post on the blog.

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.


2x upscale

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.


mobile phone camera on flat tv screen

The future
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!