Hacker News new | past | comments | ask | show | jobs | submit login
NES Graphics – Part 2 (dustmop.io)
107 points by dustmop on June 8, 2015 | hide | past | favorite | 8 comments




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.


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.


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?


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


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!


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


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: