

NES Graphics – Part 2 - dustmop
http://www.dustmop.io/blog/2015/06/08/nes-graphics-part-2/

======
ashmud
Part 1 was discussed here:
[https://news.ycombinator.com/item?id=9454670](https://news.ycombinator.com/item?id=9454670)

------
devindotcom
Thanks. I love reading about this (even with very little coding experience)
because you can see how these things affect gameplay when you're actually
playing. Little tweaks here and there to get around rules and produce a
compelling experience with extremely limited resources. Amazing what they were
able to create on the early-gen consoles.

~~~
digi_owl
Part of it came from the cartridge based system.

I think part one touched on how later carts would have an arrangement of RAM
and ROM so that what the NES thought was graphics ROM was actually RAM that
would be fed from different ROM segments based on signaling from the game
logic.

This allowed later games to have very complex worlds as the graphical elements
were replaced over time.

The SNES pushed this even further by allowing carts to carry coprocessors that
connected to the SNES board via a special row of pins.

I suspect the last hurrah of this kind of hardware over software thinking was
with the PS3 and its Cell architecture.

Both the PS4 and Xbox One use "bog standard" AMD APUs (basically CPU and GPU
on a single die) by comparison.

~~~
sopooneo
I thought something like the ROM/RAM mixing in cartridges must be the case.
But then how on earth do people make _files_ of those games that can then run
on emulators?

~~~
pcwalton
People have assembled lists of all known cartridge configurations (as many
games tended to share the same overall configuration), and assigned them IDs.
The ROM specifies, in its header, the ID of the cartridge configuration it
needs. (In NES jargon these are called "mappers" [1].) The emulator is
expected to hard-code support for every single mapper; this is, of course, a
huge nuisance and source of complexity, but there's little that can be done
about it.

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

------
tsumnia
Wish I'd seen this two weeks ago, I was just covering how the computer stores
graphics.

Thanks, I'll be sure to use this in the future!

------
ericfrederich
Interesting... I wonder if an emulator could exploit the double wide nametable
to get wide screen support

~~~
pcwalton
Unfortunately it's not that simple, as cool as that would be. Games generally
don't expect the parts of nametables that are off screen to show up, and if
you render them you'll see glitches. For example, the off-screen nametables in
Super Mario Bros. contain partially unrendered parts of levels. Even for
simple games like Lode Runner, the game won't draw sprites in parts of the
nametable that are off screen.

