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 desingers considered sufficient for all games they where required to make the chip for? After all, why spending more resources and thus money in echa chip produced than neccesarry?

So what exactly was the limiting resource?

This quetion is way to broad to have a suitable answer. Ofc, 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 overlaping, thus making the number of sprites displayable arbitary large. Same goes for the sprite data itself. So no memory cycle at all (except for creating and moving them) would be needed.

But lets 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 wasting money on developing more costly chips?

Not to mention, that sprites in themself are only crutches to enable picture manipulation for CPUs that are not fast enough to redraw a changed picture right in time. 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 extreme detailed and animated game like Xenon 2 did run as smooth on the ST.

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

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.