You see, if you need more than 10 sprites, copyng up to 128bytes each time can be heavvy.

PS
collision detection ?
you mean 5h sprite

If I've understand both routines, you can merge them adding to the Viejo's cycling the 5th sprite detection as you don't need to shift the data if the bit flag is not set; this way you can save some work.

Note that the routine must be really fast in VRAM transfers because a *good* flickering routine is one that works at full fps to make the flickering less noticeable. I think both are ok.

my routine, if the 5th sprite flag is not set, does not cycle

read the asm


....


it means that it does not cycle if there is no 5th sprite,
you can trust me if you do not see it

about your example there is a mess between sprite planes and sprite numbres

say that you display 10 sprites

A B C D E F G H I L

and that

A B C D E F G H are on the same line and are on planes 0 1 2 3 4 5 6 7,
while I & L are elsewhere on planes 8 9

the initial association sprite/planes looks like this
A B C D E F G H I L
0 1 2 3 4 5 6 7 8 9

step 1)
E F G H are hidden by A B C D, (I & L are visible), S0 -> 4
my routine rearranges the sprites like this:

E F G H I L A B C D
0 1 2 3 4 5 6 7 8 9

step 2)
A B C D are hidden by E F G H, (not by I & L that are elsewhere), S0->6
my routine rearranges the sprites like this:

A B C D E F G H I L
0 1 2 3 4 5 6 7 8 9

and so on.

As you can see the routine works perfectly, only the sprites that should disappear actually disappear
and their flickering frequency is 25Hz, i.e. the best you can get on MSX1 and 8 sprites on the same line

[edit]
Now I see your point, you was referring to the Viejo's solution, with fixed increment of the offset
Sorry I misunderstood, I tougnt you was referring to the offset guided by S0,
Yes, the problem you mention can occur with the Viejo's solution.
[/edit]

both routines rotate the sprites, one cyclically (his), one guided by the VDP S0 (mine),
apart this aspect (that is the sole true difference from the point of view of the final effect),
his code rotates the sprites with a duplication of the sprite attributes in RAM,
my code rotates the sprites with a two step ram->vram copy.
Those latter are unessential details related to the implementation, not to the algorithm


[edit]
Now I see your point, you was referring to the Viejo's solution, with fixed increment of the offset
Sorry I misunderstood, I tougnt you was referring to the offset guided by S0,
Yes, the problem you mention can occur with the Viejo's solution.
[/edit]

Right; but anyway I've been thinking about it and there're some other hidden problems. As I'm getting curious about the display quality I'll try to implement every solution posted here together in a sprite demo. I want to see the routines working on screen 


Indeed!

Do not forget to update the SAT in RAM at each interrupt and set _ready = 1
If you do not set _ready = 1 at each interrupt the routine does not work

IMHO you could remove the _ready test, it is actually usefull only in my program

let me know the results of the comparison!

PS
naturally my solution is the best
(sometime)

Ups... and what about rotating the screen 50 times per second? One hand to rotate the screen, the other for the joystick... I'm sure no flickering would be seen by the user ;-)