I have one question about how old computers or consoles like Super NES merged background layer(s) and spirites. Or another way - how layers were merged to not overload a PPU / CPU? OR how about situation, when there were more spirites on the same position? Were there all pixels of all sprites drawn?

Example:

Example

Example is based on NES, but i'm also interested in other solutions. On the picture above you can see well known and liked Mr. Gumba. Mr. Gumba is 16x16 sprite. Some of the pixels in memory has value h00, that means, that this is "transparent" color. As far as I remember - SNES were able to display parts of 6 backgrounds on the same time

So how this layer below were displayed? This was made without buffering. Was it something like:

  1. Load to a register pixel color from (top) object memory.
  2. If it is transparent load to a register pixel color from memory of object that is below.
  3. If it is transparent load to a register pixel color from memory of object that is below.
  4. If it is transparent load to a register pixel color from memory of object that is below.
  5. If it is transparent load to a register pixel of background
  6. Display

(?)

closed as too broad by JAL, wizzwizz4 Feb 21 at 17:06

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    This question is way to broad, as next to evry platform had a different solution. It would be nice if you could focus that down to one system/graphics hardware (like the NES). Otherwise it won't fit the RC format. Thanks. – Raffzahn Feb 20 at 18:28
up vote 5 down vote accepted

It's usually not as centralised as you describe.

If a system supports a background and, say, four sprites then there'll be one part of the video chip that generates the background. That's always running. Then there'll be four distinct shift registers, each responsible for a single sprite. They're also always running.

The five outputs go simultaneously to a single location. That location decides which one to forward to the video encoder, and often also updates a bit of exposed state about whether more than one of its inputs was active at the same time, which the processor can use to test for collisions.

A sprite that is in practice entirely invisible will nevertheless be loaded into its shift register and shifted out in its entirety.

So the process is parallel, not serial.

Then sprites-per-line limits from there being space for only so many shifters; there's a split between machines where you directly load hardware registers to describe sprites (like the C64), and those which fetch sprite details from RAM somewhere (like the TMS machines and direct descendants). The difference tends to manifest as whether the programmer can statically specify more sprites than can simultaneously share a line; the cost is that a bit more memory bandwidth is required for the same quality of display. The earliest successful console, the 2600, not only sits in the load-the-registers camp, but includes its background in the list of things that must be loaded and has enough internal storage for a single unique line only.

Later machines also abolish the fixed priorities between elements, allowing it to be specified.

  • 1
    If you assume that these systems ought to minimize the amount of circuitry needed for a certain level of graphical detail (and especially, to minimize the use of RAM), and that they need to run at an absolutely constant pixel rate (because there's no framebuffer to use as working space), they almost design themselves. Just push out pixels one (or maybe two or four) at a time and never stop. – hobbs Feb 21 at 1:41

Not the answer you're looking for? Browse other questions tagged or ask your own question.