

NES graphics – Part 1 - dustmop
http://www.dustmop.io/blog/2015/04/28/nes-graphics-part-1/

======
jonny_eh
I love articles like this. It reminds me about a similar one about the Super
Game Boy: [http://loveconquersallgam.es/post/2350461718/fuck-the-
super-...](http://loveconquersallgam.es/post/2350461718/fuck-the-super-game-
boy-introduction)

------
6502nerdface
Great, approachable introduction to how NES graphics work under the hood;
looking forward to Part 2.

In the meantime, interested nerds can feast on the wealth of information
available at [1], which, though a bit disorganized, goes deep into the
implementation of the NES's Picture Processing Unit and its programming
interface.

[1]
[http://wiki.nesdev.com/w/index.php/PPU](http://wiki.nesdev.com/w/index.php/PPU)

------
aout
During that time, Nintendo knew how to work with game studios. The color
palette is one of the most powerful examples I remember, it encompasses the
technical and the artistic domains, developers and designers. With the SNES
they got even further by adding composition in a way that was incredibly
intuitive. Glad you produced this article. So much memories.

~~~
chii
> it encompasses the technical and the artistic domains

these days, the amount of knowledge required in those two domains are such
that no one person can be an expert in both ( at least,for a non-genius!).
Think about 3D artists, and think about people who write the pipeline and
tools etc for them - one does not know anything about the other really. I wish
there's a way to simplify it all so that modern games can be made just as
"simple" and intuitive as the old 2D bitmapped graphics.

~~~
aout
True, but today's studios need the proper APIs and hardware to produce the
games people want. Nintendo is failing to provide such basis for development
and that's one its biggest mistakes.

------
tbrock
To me it seems as if the PPU is the most poorly explained (or difficult to
understand) component of the NES. Most documentation heavily glosses over
details and specifics or doesn't provide any reasoning as to why such a system
was designed. This is a great guide.

If you have some spare time and want to tinker a bit, writing your own NES
emulator is a great way to learn something new (or learn a new language if
you've done it before)

~~~
loganfsmyth
Definitely second writing your own as a way to learn. I wrote one that could
mostly play pong a while back and it was super satisfying. The PPU was
definitely the toughest part.

------
otabdeveloper1
> Original NES developers probably had some sort of toolchains, but whatever
> they were, they have been lost to history.

"Lost to history"? Really? The developers are still alive, you could have, you
know, sent them an email and asked.

~~~
bluedino
This webpage:

[https://seanmalstrom.wordpress.com/2011/08/19/email-a-
look-i...](https://seanmalstrom.wordpress.com/2011/08/19/email-a-look-in-
nintendos-offices-1989/)

shows Nintendo programmers plugging away at HP 64000 which was likely
corporate-owned and long destroyed

[http://en.wikipedia.org/wiki/HP_64000](http://en.wikipedia.org/wiki/HP_64000)

------
rcr
What advantage is there to storing the high and low bits of the 2 bit depth
CHR separately, as mentioned in footnote 2?

~~~
muhbitplanes
This is the ol' chunky (all of the bits for a pixel stored adjacently in
memory) vs. planar (image broken up into separate "bitplanes") graphics
debate. Planar was very common for early 2D hardware, as it was the natural
extension of 1-bit monochrome display hardware, which would load a byte at a
time into a shift register, shifting a bit out per pixel clock. Instead of
needing to redesign the hardware around a larger shift register, you could
just duplicate your existing shift register, shift them out in parallel, and
combine the results with some simple logic.

It had a variety of benefits for simple 2D composition. For instance, it
allowed for flexible bit depths in video modes. The Amiga (IIRC) allowed you
to set up video modes with anywhere from 1 to 5 bits per pixel, while the SNES
allowed 2, 4, and 8 bits per pixel formats; lower depth modes would simply
load the unused shift registers with 0s, and everything would work the same.
With chunky pixel hardware, this would have been unfeasible at the time, as
the pixel format packing would change too much between bit depths. It was a
handy feature to have, so that, say, text in an RPG could be placed on a
monochrome layer that would not take up as much video memory, while the rest
of the game could be rendered in full color.

The NES doesn't support flexible bit depths, but a similar principle allows a
simple kind of "compression" when storing compressed graphics data in ROM: for
a monochrome font, you wouldn't need to store the upper bitplane, and you'd
just zero it out when loading the font. For chunky hardware, this process
would be a bit more involved than that (no pun intended).

Of course, once you advance beyond simple 2D composition to software
rasterization, the planar format becomes a liability. Rotating and scaling a
bitmap, for instance, would involve making multiple unpredictable read-modify-
write memory accesses per pixel, instead of just directly overwriting a pixel
at a time.

Here are some links that discuss some of the other tradeoffs of the two
formats, like how you can use planar formats to implement simple alpha
blending effects for shadows and the like:

[http://oldwww.nvg.ntnu.no/amiga/amigafaq/AmigaFAQ_16.html](http://oldwww.nvg.ntnu.no/amiga/amigafaq/AmigaFAQ_16.html)

[http://www.sega-16.com/forum/showthread.php?9265-For-the-
Tec...](http://www.sega-16.com/forum/showthread.php?9265-For-the-Tech-Guys-
Planar-vs-Chunky-Pixel-organization)

~~~
greggman
> The NES doesn't support flexible bit depths, but a similar principle allows
> a simple kind of "compression" when storing compressed graphics data in ROM:
> for a monochrome font, you wouldn't need to store the upper bitplane, and
> you'd just zero it out when loading the font.

I don't remember NES having many carts having the ram available _load_ fonts.
fonts were in rom and directly read in rom by the hardware. Or am I just
forgetting some option on certain carts that allowed fonts in ram?

~~~
muhbitplanes
The NES has separate address spaces for the CPU and PPU. Part of each is
mapped to internal memory and IO registers, with the rest available for the
cartridge to do whatever it wants with. The PPU doesn't care if you map RAM
("CHR-RAM") or ROM ("CHR-ROM") into its address space for holding graphics, it
just reads whatever is there, so both are commonly used in games. The IO
registers used to update tile and palette indices in the "nametable" can
access any part of the PPU's address space, so in a CHR-RAM cart, they would
also be used to fill the CHR-RAM with graphics. In this case, you absolutely
could use any compression scheme you want (within reason) to compress the
graphics stored in PRG-ROM. Of course, with a CHR-ROM cart, you'd be limited
to storing uncompressed tiles in the CHR-ROM.

NES games are interesting because there's such a variety of hardware in the
cartridges and techniques to make the most of it. There are games with huge
PRG (CPU-visible) ROMs that stream data into CHR-RAM. There are games with
huge CHR-ROMs and mapping hardware for granting fast, fine-grained access to
more tile memory than would fit into the PPU's address space. There are games
that store level data in unused CHR-ROM, and even a few (IIRC) that store game
variables in unused CHR-RAM! Programmers made the most of whatever hardware
was cheaply available to them.

------
userbinator
One way to think of it is basically as a text mode with customisable graphics
for each character. It's also possible to "race the beam" and change them
between lines, giving rise to far more interesting effects.

------
faragon
Very well explained. I hope next parts will address screen scrolling, sprite
animation, and "raster effects".

------
unexistance
very good read... pretty sure these knowledge have their place in our modern
scenario, say like sensors?

------
Zardoz84
Interesting. Looks like that it evolved from a text only video system, but
using 2 bit shade per character and selectable palette per character. Indeed,
very clever.

------
blt
cool post! the development process must have felt so different then.
constraints bring out creativity. today's hardware is amazing, but there's
something special about knowing every corner of a system, working right on the
metal. it might even be within reason to imagine building a system like this
out of 74 series logic in the garage...

------
distantsounds
This is an amazing read. Thanks.

------
grimmdude
Very interesting

