Sprite split

I would like to know if this is actually true?

Whenever I look at replays it seems they use roughly 8 sprites for the player and its weapons, and 24 for enemies + bullets + explosions. But nothing more.

Most likely they alternate sprite priorities to counter flickering like many other games do, but I don't think there is actual sprite multiplexing going on there?

Hmm okay maybe I am wrong. For the player I can count:
fighter = 2
max 3 fighter bullets = 3
2 options = 2
max 2 bullets per option = 2 * 2 = 4
missile = 1
So this would be 12 in total for the player.

Which leaves roughly 20 sprites for the rest.

However, I can see the Lobster boss shoot 12 blue projectiles which seem to be multicolored and would thus require 2 sprites per projectile, adding up to 24? (although I see a couple of player projectile sprites disappear then, so maybe there is a shared pool for some player projectiles and the rest?)

Interesting

well a sprite split is very comparable to a screen split. You poll the lineint and then switch to another spritetable. If you change the lineint during the split you can do multiple splits per frame allowing many sprites in screen. Handling it nice and smoothly is another art though.

Varying from terrible to extremely bad Depending on how you handle it all good to white nasty lines or even broken sprites. Because the next line you start drawing the sprites the sprite that was in the other split is no longer being drawn. So you need to have copies of your spritedata and do the changes smoothly and that will cost you alot of CPU time.

I made a sprite test program for my C library that uses screen-split to change the sprite display parameters: s_sprite.rom.
The screen-split is at the same time a very powerful tool that allows to get rid of some VDP constraints, but its use is quite limited because it is very specific.
Unless you think of a specific game to take advantage of these advantages, it is likely to be of little use to you.