Limiting factor on sprite sizes

Early consoles and home computers that were optimized for games, tended to provide sprites. From a game programmer's viewpoint, these were good to have. Of course, one always wanted more and larger sprites, suggesting that it bumped up against some resource limit. But I'm trying to understand what the resource limit was, because the observed pattern is surprising.

• Atari 800. 8 sprites, 2 or 8 pixels wide.

• Commodore 64, 8 sprites, 24 pixels wide. You could use raster interrupts to multiplex on different scan lines; in all cases here, I'm talking about the limit per scan line. Also, the pixel width could be doubled, but at the cost of halving resolution; the number of bits in each sprite per scan line was constant.

• NES. 8 sprites per scan line, 8 or 16 pixels wide.

• Amiga. 8 sprites per scan line, 16 pixels wide.

https://en.wikipedia.org/wiki/Sprite_(computer_graphics) gives figures for some other machines; while the limits were increased in later years, the above figures tended to apply in the early eighties.

So that's machines spanning six years of time, multiple iterations of Moore's law, one or two orders of magnitude of available transistor count, but the sprite limits are strangely constant, which is surprising if transistor count is the limiting resource. Or does the number of transistors required to implement N sprites per scan line of W width, increase superlinearly with N or W? It is true that sprites tended to consume a lot of chip area (reported 2/3 to 3/4 of the Commodore 64 VIC-II; by eyeball from an annotated die photo, at least half of the NES PPU), but the available chip area would not be expected to stay the same over that length of time.

And it doesn't seem like it should be memory bandwidth; at least the description in When does the VIC-II read the sprite data? doesn't seem like the bandwidth requirement should depend on N or W.

So what exactly was the limiting resource?

• Trying to apply Moore's law on something that is not generally usable or even needed (there's only so many sprites you can reasonably place in 256x192) is probably wrong. Not taking sprite height and # of colors into account probably as well. Nov 18 '17 at 20:16
• Guess: What's really limiting sprites per scanline is the time required to process the transparency - in the worst case, all sprites are involved. And while transistor count and processing speed went up over time, frame buffer size also went up, so there's less time to process a single pixel. But to really find out, you'd have to look at a reverse-engineered graphics chip. Nov 18 '17 at 20:35
• What was really limiting sprite size was the availability of sufficiently accessible and complex custom chips - The original Amiga Inc was driven into foldup (takeover) trying to develop them, Commodore could build the VIC in MOS, the others had to revert to what the market had to offer - And that was not much. Home computing was still a niche market for chip vendors in the 80ies. Nov 18 '17 at 22:03
• "So that's machines spanning six years of time, multiple iterations of Moore's law" -- this is simply not true since for example VIC-II and amiga OCS chipset were both using 5um technology. Home computers were not at the top notch technology during 80ties.
– lvd
Nov 19 '17 at 0:00
• " doesn't seem like the bandwidth requirement should depend on N or W." -- actually it does. For example, bad lines on C64 with the addition of sprite fetches could leave for the CPU just 3-4 clocks available out of the maximum 63 clocks per line.
– lvd
Nov 19 '17 at 0:03

Actually, the most probable limit was the amount of the on-chip RAM to hold sprites. To my knowledge, sprite circuitry, including sprite on-chip RAM (or just flip-flops) were responsible for the majority of silicon space in VIC-II chip.

In all the architectures @rwallace listed none were able to buffer even the single line before actually outputting it to TV: memory fetch was synchronous to the pixels outputting. Hence, the sprite data had to be fetched ahead of time and outputted just at the required moment when sprite coordinate comparators fire. The need to pre-fetch and store sprite data on-chip follows from this. Therefore silicon area, rather expensive at the time, limited the size and number of sprites available on those architectures.

• The question wasn't why it was hard in 1979 (Atari 800) to do more than 8 Sprite, but why it still wasn't done in 1986 (Amiga), when RAM sizes have moved from a few kilobytes into megabytes, and CPU transistor counts got tenfold or more. Nov 18 '17 at 23:51
• Because on-chip RAMs were still a luxury. Don't mix separate RAMs like DRAM chips and ON-CHIP RAMs that in the best case could be SRAMs, and in the average just flipflops arranged in a shift register.
– lvd
Nov 18 '17 at 23:52
• As I explained in the comment to the question, OCS amiga used the same 5um technology as VIC-II does. So there were no real improvement in the number of transistors for the amiga, with the only probable exception of the greater available chip size. Meanwhile, amiga video circtuity was much more versatile and capable requiring more transistors to do the job.
– lvd
Nov 19 '17 at 0:13
• If we look at the Amiga specifically, it didn't need lots of hardware sprites because it a had really powerful blitter which was much more versatile. Atari ST didn't have hardware sprites at all, so it seems that industry was moving away from sprites in general. Though for consoles, Neo Geo in 1990 went to the other extreme with everything including scrolling backgrounds being huge sprites (96 sprites (à 16 pixels) per scanline). SNES also had substantial amount of sprites (32 per scanline, up to 64 pixels) Nov 19 '17 at 3:24
• Also, if we look at the relative prices of the machines, Atari 800 was expensive. Commodore 64 was half the price (less if we factor inflation). NES was cheap. Taking another point of comparison: ZX Spectrum was cheap and had no sprite hardware at all. So even if the capabilities didn't increase by a lot, the price came down a lot. Nov 19 '17 at 3:31

On most of those early systems, the scan line data for the sprites was fetched from main memory during the horizontal blanking interval prior to each display scan line, which is a fixed amount of time in NTSC or PAL video timing. So the number (and width) of sprites was limited by memory bandwidth (which was limited by memory data bus width and DRAM cycle time).

In general, memory bandwidth improvements lagged behind increases in the transistor counts predicted by Moore ‘s Law. Also, large enough on-chip memories, such as for data caches, were not common until much later, around the time of the 68030.

• Do you know if this was the case specifically for the Ataris and C64? May 13 '19 at 14:03

So that's machines spanning six years of time, multiple iterations of Moore's law, one or two orders of magnitude of available transistor count, but the sprite limits are strangely constant, which is surprising if transistor count is the limiting resource.

Or maybe 8 sprites per scan line is something that chip designers considered sufficient for all games they where required to make the chip for? After all, why spend more resources and thus money in each chip produced than necessary?

So what exactly was the limiting resource?

This question is way too broad to have a suitable answer. Of course, it would be possible to hold all sprite coordinates in on-chip registers and use dedicated logic to compare each sprite position vs. each other to detect and resolve overlapping, thus making the number of sprites displayable arbitarily large. Same goes for the sprite data itself. So no memory cycle at all (except for creating and moving them) would be needed.

But let's be honest, do we need anything more sophisticated? Looking at existing games show that much of the benefits of such a system, if not all, can be reached by clever handling of the existing setup. So why waste money on developing more costly chips?

Not to mention that sprites in themselves are only crutches to enable picture manipulation for CPUs that are not fast enough to redraw a changed picture quickly enough. With faster CPUs the need for sprites vanished. While the Amiga still had sprites, the Atari ST only offered a plain bitmap. Still a rather extremely detailed and animated game like Xenon 2 did run smoothly on the ST.

So simple answer, extending the resources to handle more sprites would be a solution without a problem.

• Concur with your bold paragraph 100%. Rest of your answer seems to assume "custom video chips were easy/trivial" - They weren't. Not a lot of HCs really have complex custom VICs. Nov 19 '17 at 9:52
• While eight sprites per scan line is not in general sufficient for games, in the context of the Amiga, it could well make sense for the designers to say 'okay, we have sprites lest it be said we left out a feature, but they aren't top priority because we expect people to be able to just use the blitter'. Nov 19 '17 at 12:23
• Considering the amount of special tricks to increase sprite limit perused by any larger game of that era, I'd say your claim that 8 sprites are "sufficient" is largely groundless - it's obvious that games required more sprites to render. Your post doesn't really answer the question. Jan 2 '19 at 1:57
• @Mavrik Games will always be able to use up more resources. The question is if these resources can be provided at a reasonable effort (cost) by chip designers. Same way why CPUs got only a certain amount of on chip registers. We all know would love to have more, don't we? What you call 'tricks' is intended usage. Compare the (late) Amiga with as well only 8 hardware sprites - already the first page of the manual talks about reuse. No trick, just standard usage. Jan 2 '19 at 7:47
• Xenon II was sluggish on the Amiga, just as it was on the ST. Of course, Amiga owners perceived it as more sluggish since they were used to faster screen updates. May 15 '19 at 16:08

Memory bandwidth was usually the limiting factor. The video generation hardware has to fetch data for the background image and all sprites from memory. On most 8/16 bit systems this was done "on-the-fly", as the screen image was being generated. As such memory speed placed an absolute limit on the amount of data that could be fetched in the time available, which was typically only one scanline or 64uS on a PAL system.

Memory bandwidth also had to be shared with other devices. Typically the video generator hardware would get priority in order to avoid the screen breaking up. Whatever was left would be available for the GPU, CPU, sound, disk and other hardware to use.

For example, the Amiga has a total of 226 memory access slots available per scanline. Of those, 80 are allocated for background graphics, 11 for various other things and 16 for sprites. That leaves 119 available for the CPU and the Amiga's graphics accelerator (blitter). So the Amiga could actually support more sprites, at the expense of other functions, but other systems were often more limited.

You can see the result of this on certain machines, most notably the Nintendo Famicom / NES. Sprite flicker was common in Famicom games, and was caused by the system not having enough memory bandwidth to fetch graphic data for all the sprites on a given scanline.

Many systems limited the available number of sprites to make flicker impossible, but the Famicom designers decided to allow the programmers greater freedom to manage sprites themselves and decide on the best trade-offs.

The increased transistor count was used for more colors. The Amiga wants to show off its blitter. PAL has 64 µs period of which 52 µs are used to display something. The rest of the time is used in the computer for different stuff. While the NES allows VRAM writes only in this period, shared memory architectures like C64 and Amiga use this to read the sprite data. The C64 has some sprite-slots which block the CPU. The Amiga wastes some cycles on copper.

Sprite data and one line of characters are stored in ring-buffers in the VIC-II, no random access. So transistor count scales lineary. Also: no left-right flip. Sadly the sprite ring buffers are not really rings, but open, and sprite data can not be written to screen multiple times (like zoomY of CPU-blocking sprites, or array of sprites like on Atari 800 space invaders or Amiga Sprite Backgrounds).

Also the NES has 4 color backgrounds at 256 px while C64 only has 160px. Also NES stores more sprites and muliplexes in fast hardware => transistor count goes up. Aparently ROM module bits are to expensive for a software sprite multiplexer.

The way that sprites were mostly generated by the video chip and over-imposed on a background image, together with the fact that screens are rendered line by line by the video chip lead so some interesting concepts, like doubling of sprites by switching between different sets of sprites at a certain scan line. A number of professional games on the Commodore 64 were using this technique. Which opened up a new set of limitations, based on the speed to manipulate the chip registers in the beam return gap. Using this technique you could for example use the same sprite multiple times on the screen in different positions. Further advanced you could even change the look of sprites, but this was so CPU time consuming that it would mostly require you to have a "empty" space (like a cockpit frame) to give you enough time to change the sprite look and not just double up on positions, sometimes resulting in some sprite tearing at the switchover line. The ultimate limiting factor to what you could do with your sprites was the CPU speed since all of the clever ways to get more use out of sprites required highly optimized machine code and without any reasonable fast way to manipulate the "Background" video, most of you moving objects had to use sprites. Due to the different architectures you can not easily compare the trade-offs of the different system sprites, since they had inherently different limitations. All in all sprites were great because they allowed developers to program games with moving objects that were otherwise not possible due to the slow CPU and missing GPUs of that time hardware.