Now I see, when you say "remove" you mean placing the sprite outside the
screen (e.g. y=212), not skipping its plane in the SAT when you update it.
Assuming you mean this, everything make sense, as rotating the SAT in
sprite mode 2 is absolutely cumbersome (512+128=640 bytes per frame).
Yes.
BTW, the case you depicted is a bit "theoretical", in the sense that you cannot
be sure that removing 4 sprites before the one in S0 will guarantee that S0
is displayed... To be sure you should remove at least S0-7 planes before S0
(and this can imply a HUGE flickering...)
Yes, Assuming i have 16 sprites on the same line aligned, the vdp will report 8.
So, removing only 4 sprites enable the vdp to display at least the sprite number 8-9-10-11 (because i hide the planes 4-7)
Of course the greater number of sprites (max = 8 ) you remove at every frame the higher the flicker frequency you achieve at the cost of a big number of sprites flickering.
In the above situation, removing 8 sprites at each frame will achieve a 25 fps flickering freq.
Basically the algorithm is this:
const nspr = 8; // number of sprites to remove at each frame;
function int38h()
{
if (i_have_to_many_sprites)
{
updatevramsat(plane_base_index, nspr); // calling this will update y pos to 216 starting at plane_base_index for nspr planes
plane_base_index+=nspr; // number of sprites to remove at each frame
}
else
{
write_Sat_as_Is(); // write the sat without boring of sprite limits
plane_base_index=0;
}
}
So i will continue to remove chunks of nspr sprites until the vdp says "OK, no to many sprites". Really i use only the s0 reg to know the overflow situation;
In my specific situation i've added also the option to make the first 4 planes fixed, but this is only because i do not want the main charater to flicker.
If it's not clear feel free to reply to this.
