NES graphics – Part 1
dustmop.io
dustmop.io
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.
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.
Source: http://www.thealmightyguru.com/Games/Hacking/Wiki/index.php?...
I highly doubt this is because it was "poorly chosen" - it seems this must be due to some sort of technical limitation.
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)
"Lost to history"? Really? The developers are still alive, you could have, you know, sent them an email and asked.
https://seanmalstrom.wordpress.com/2011/08/19/email-a-look-i...
shows Nintendo programmers plugging away at HP 64000 which was likely corporate-owned and long destroyed
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://www.sega-16.com/forum/showthread.php?9265-For-the-Tec...
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?
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.