Limiting factor on sprite sizes

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.