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:
> 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|11 years ago
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...
greggman|11 years ago
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?