How The NES Displayed Large Enemies

Creative ways developers overcame the original Nintendo’s sprite limitations

Link fights the Rebonack at the end of the Island Palace.

Creative ways developers overcame the original Nintendo’s sprite limitations

The original NES has some strict limitations around how many sprites, or graphics, it could display at one time. First off, a single sprite could only be 8 x 8 pixels made up of a three-color palette, not including one color reserved for transparency. On top of this limitation, the PPU (Picture Processing Unit) could only display 64 sprites on the screen, and only eight could be on a single scanline. To get around this, developers had to do some fascinating tricks to display large enemies on the screen.

While many great articles are explaining how the original developers for the NES were able to get around these limitations, I thought I’d highlight one instance I noticed while playing Zelda II.

Later in the game, Link has to fight the Rebonack boss at the Island Palace. The knight and the horse consist of multiple sprites rendered together to give the impression of a single entity, just like Link. But the developers of Zelda II used some neat tricks to animate the knight and horse on the Nintendo’s limited hardware.

At the edge of the screen, sprite disappears to keep them from wrapping around to the opposite side.

Here I am capturing the raw RGB output from my Twin Famicom. On CRT monitors, the edges of the screen would have been cut off like this. By default, the NES could account for this clipping and could even be flagged to remove an entire column of tiles from the screen.

The edges of the screen would have been hidden by a CRT monitor.

If we slow down the animation, we can see how the knight is a combination of multiple sprites. This is more apparent when it gets close to the edge of the screen.

You can see each of the sprites that make up the knight disappear at the edge of the screen.

In fact, the sprites are removed when they cross the left border of the screen to keep them from wrapping around to the opposite side. If you look close enough, you can see a bit of the knight still wraps around the screen before the sprites disappear.

A shot of the sprites offscreen wrapping around to the opposite side.

The other thing you’ll notice in this battle is that the level isn’t scrolling, and there are no other sprites on the screen. This gives the enemy the full amount of sprites the NES can display, after taking into account Link’s animations.

The knight being knocked off its horse.

But what caught my attention was what happens when Link finally knocks the knight off of the horse. You can see a 2nd knight appear for a split second before the horse sprites change to over to not having a rider. Even more interesting is that only the back half of the horse sprites change. You can still see the lance the knight was holding on the horse as it goes off-screen.

The second knight appears before the original is taken off the horse.

Reusing as many sprites as possible was another trick NES developers used to get around the strick memory limitations. They were only able to store a small number of sprites on the cartridge, so the animations were simplified as much as possible. It would have taken too many sprites to show the knight getting off the horse. Most of the sprites of the knight are shared between him being on and off of the horse.

The knight sprites are shared to cut down on storage space.

You can see this in the top part of the knight and his back cape. This way, they could quickly switch between the mounted knight and the standing knight when Link knocks him off.

I’ve been fascinated with how developers have been able to work around these limitations and was heavily inspired by this when creating my Fantasy Console, Pixel Vision 8. With a little bit of planning, it shouldn’t be hard to recreate some of the same techniques used on the Nintendo to get the most out of Pixel Vision 8’s sprite renderer.