I wish you could pick any of the four palettes freely for each tile though. Nevertheless, V9990 is a pretty strong proposition. Only downside is availability and the pattern modes being 15 kHz-only (how hard is it to make a scandoubler).
I recently wrote some V99x8 code for softsprites; worst case, save-draw-restore softsprites take 12 draw calls in stead of 3, it costs a lot of VDP time to draw.
And as for V99x8 sprites, y=216 is such a useless and annoying function, why aren’t sprite colours looked up by sprite attribute number in stead of the pattern number, and who on earth thought it was a good idea to specify early clock (EC) per-line in stead of per-sprite (16 outs to change EC!). Sorry, had to vent some frustration on the design 
.
12 draws calls? why?
And about the EC per line, it is because them hack up the v9918 design. Enginners didn't go deeper in the hardware sprite engine, them just change the way that engine is feed with information in a per line..., them already had EC + COLOR in the attribute table, and a way to increase the colour was changing one color per sprite by one colour per line, so them do it feed up that same byte per line, reading from a table, instead of the same fixed location from the main spr att table.
Also them use that same byte to add the other two bits functionality.
It is the law of the minimal effort, lowering the cost, minimizing dev time.
I recently wrote some V99x8 code for softsprites; worst case, save-draw-restore softsprites take 12 draw calls in stead of 3, it costs a lot of VDP time to draw.
12 draws calls? why?
One for save, one for draw and one for restore. However, if the sprite is on both an x and y screen boundary, all three draws need to be split both vertically and horizontally, resulting in 12 draws in total.
I understand the legacy reasons for the sprite design, wanting to reuse transistors between sprite modes 1 and 2, but it’s annoying nevertheless . Especially the EC bit was rather shocking to me to find out that they changed it in such a way, it changed from a relatively easy way to specify coordinates in the left border of the screen into something quite more complicated and expensive to work with.
I recently wrote some V99x8 code for softsprites; worst case, save-draw-restore softsprites take 12 draw calls in stead of 3, it costs a lot of VDP time to draw.
12 draws calls? why?
One for save, one for draw and one for restore. However, if the sprite is on both an x and y screen boundary, all three draws need to be split both vertically and horizontally, resulting in 12 draws in total.
I understand the legacy reasons for the sprite design, wanting to reuse transistors between sprite modes 1 and 2, but it’s annoying nevertheless . Especially the EC bit was rather shocking to me to find out that they changed it in such a way, it changed from a relatively easy way to specify coordinates in the left border of the screen into something quite more complicated and expensive to work with.
Ah, it is because you do SAVEs, with my engine in the worst case it do 8. If X & Y boundaries, one for draw, and other for restore. No save is required, no "sort" is required, nothing on that bothering the run.
