Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NES graphics – Part 1

dustmop.io

Post reply on HN
Print view View original

11–20 of 29 posts

Re: NES graphics – Part 1

#11

Post by muhbitplanes »

rcr wrote: post #8

What advantage is there to storing the high and low bits of the 2 bit depth CHR separately, as mentioned in footnote 2?

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:

http://oldwww.nvg.ntnu.no/amiga/amigafaq/AmigaFAQ_16.html

http://www.sega-16.com/forum/showthread.php?9265-For-the-Tec...

Re: NES graphics – Part 1

#13

Post by greggman »

muhbitplanes wrote: post #11
rcr wrote: post #8

What advantage is there to storing the high and low bits of the 2 bit depth CHR separately, as mentioned in footnote 2?

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 large…

> 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?

Re: NES graphics – Part 1

#14

Post by userbinator »

One way to think of it is basically as a text mode with customisable graphics for each character. It's also possible to "race the beam" and change them between lines, giving rise to far more interesting effects.

Re: NES graphics – Part 1

#16

Post by muhbitplanes »

greggman wrote: post #13
muhbitplanes wrote: post #11

Earlier quoted context omitted.

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 large…

> 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 j…

The NES has separate address spaces for the CPU and PPU. Part of each is mapped to internal memory and IO registers, with the rest available for the cartridge to do whatever it wants with. The PPU doesn't care if you map RAM ("CHR-RAM") or ROM ("CHR-ROM") into its address space for holding graphics, it just reads whatever is there, so both are commonly used in games. The IO registers used to update tile and palette indices in the "nametable" can access any part of the PPU's address space, so in a CHR-RAM cart, they would also be used to fill the CHR-RAM with graphics. In this case, you absolutely could use any compression scheme you want (within reason) to compress the graphics stored in PRG-ROM. Of course, with a CHR-ROM cart, you'd be limited to storing uncompressed tiles in the CHR-ROM.

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.

Re: NES graphics – Part 1

#17

Post by dyselon »

greggman wrote: post #13
muhbitplanes wrote: post #11

Earlier quoted context omitted.

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 large…

> 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 j…

It's not particularly uncommon. Check out the mapper list at http://tuxnes.sourceforge.net/nesmapper.txt. All the 0k chr entries are carts that have chr ram. Just for funsies, I looked up one I had, and cracked it open so we could take a look at it. You can see on this Cobra Triangle cart the MB8464A 8k sram chip wired up to the chr lines. https://drive.google.com/file/d/0B2I5cGIsgvHbN1NFdUdLNTluNHM... It's also kind of cool to see the 74 series chips at work; the 74161 counter being used to select the prg rom bank, and the 7402 used to disable the prg rom during writes.

Re: NES graphics – Part 1

#18

Post by blt »

cool post! the development process must have felt so different then. constraints bring out creativity. today's hardware is amazing, but there's something special about knowing every corner of a system, working right on the metal. it might even be within reason to imagine building a system like this out of 74 series logic in the garage...

Re: NES graphics – Part 1

#19

Post by otabdeveloper1 »

> Original NES developers probably had some sort of toolchains, but whatever they were, they have been lost to history.

"Lost to history"? Really? The developers are still alive, you could have, you know, sent them an email and asked.

Re: NES graphics – Part 1

#20

Post by chii »

aout wrote: post #6

During that time, Nintendo knew how to work with game studios. The color palette is one of the most powerful examples I remember, it encompasses the technical and the artistic domains, developers and designers. With the SNES they got even further by adding composition in a way that was incredibly intuitive. Glad you produced this article. So much memories.

> it encompasses the technical and the artistic domains

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.

Post reply on HN