Sprite split

With some success but never applied to anything serious I was able to do all the sprite to table copies in ram during vblank and then at each line int perform the table updates. During line split if fast enough most sprites would draw fairly well. Problem is that you are limited to a amount of sprite types as updating pattern and color tables is next to impossible during the lineint.

I don’t know of anything that uses a sprite split except for Guru Logic Champ (the MSX Magazine demo version), Patriek coded it.

I think sprite splits are particularly useful for situations where you have static sprites, e.g. to overcome colour attribute clash in screen 4 images, or to have a score display at the top of the screen.

When they are moving sprites that participate in the gameplay, the computational cost of the code and data structures to support the migration of sprites between different tables as they move across the screen (and the necessary duplication) becomes quite expensive, in addition to the fact that moving large amounts of sprites is by itself already expensive.

Exactly! sprite split is useful on c64 that have more flexibility in sprites x scanline but pay a lot with the limitation of 8 sprites x screen .
By contrast msx have more limited sprites but the flexibility of 32 patterns on screen

As others have touched upon, for example, getting a full-screen, 32+32 unique sprites is hard. Even if you have a two player game with a visual split in the middle of the screen (to avoid clash), managing two sets of sprite attribute tables that also must be pushed to the VDP twice pr frame will likely take a good share of the available cycles.

In an upcoming game I'm currently working on I will use sprite split in a favourable way. I use 4 sprites on each side of the screen (border) to mask away blocky tiles, so in total 8 for this. They are first positioned sequentially from the top of the screen. At both scanline y1 and y2 and I reposition the y-pos of those 8 sprites, and "reuse them". In practise this gives me a total of 48 possible sprites on the screen at once, each frame. I really wanted the masks on each side, and if I didn't go for a split, I would have spent 24 sprites for masking alone, leaving only 8 left for the game. And with 2 sprites pr character, I would end up with a max of 4 game characters (where 1 is the player). Not very flexible.

The goal was never to have a huge bunch of sprites on screen at the same time, the goal was to have masks on the side and at the same time, have an ok amount of sprites available so I could make an ok "sprite-manager" with the flexibility that the game needed.

And it works quite well

The big enemies are sprites, not tiles, you can see it by the fact that they move pixel by pixel, they have more than 2 colors per spriteline, and you can disable them in an emulator.
The turrets are software tiles.
Spacemanbow uses a spritesplit, 100% certain.

How they do it exactly I don't know, but I would say, they probably use a variable splitline.

At Vblank you can sort all the sprites in screen by Y value.

The first 32 sprites will go in spritetable 1, and the rest (with a small overlap) go in sprite table 2.

The splitline then will be a bit above where sprite 33 starts.

And if there are <33 sprites in play the splitline will be skipped for that frame.