NES Graphics – Part 2

[ashmud]

Part 1 was discussed here: 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.

[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.