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?