copy the sprite list reverse every second time. gives 8 sprites per scanline and 64 sprites per screen.
on msx1 the sprite/scanline limit is too tight. better a rotation algoritm expecially because there is no color table to move too.
with reverse sat you get only 8 sprites that if you use multicolor sprites you drop down to 4.
@hit9918
But it works...
don't you noticed, but i wrote:
ld a,(bc) ;read ypos offset
add a,(hl) ;add it to ramspttbl ypos
sub 192 ;from 192 ycoord on, subtracting 192 <------ read here. FROM 192 ycoord on 
when 191 the sprite is still onscreen, so I wait to y192 (and in fact I subtract 192
and then readd it plus 16 to avoid deactivate sprites from -16 to 0 ypos (-16 is start y pos of some enemy patterns)
the video I posted was without sprite deactivation, wich I have implemented this morning.
I'm sorry you can't see FB videos. I haven't any alternative for posting videos.
Can't you open a FB account? else give me a mail, I'll send you the video (and if you like also a new video with sprite removing, only on y coord, implemented)
for x coord I think i cand do the same subtracting 255 for right border (have to try) and still have to implement early clock bit and then something appropriate for left border...
I missed the rest of the code doing some more things.
but still I dont like bit 7, why use the little bit 7 when you can have the big bit 8
carry is bit 8.
and then
cp 191
jr c,maybekill
is the fastest
95% of sprites run thru this in 16 cycles with the branch not taken.
about the video, the funny thing is that the first video that you posted in this thread
https://www.msx.org/forum/msx-talk/development/vertical-scro...
https://www.facebook.com/groups/msxitalia/permalink/10151700...
this is visible to all public
I really don't know why... Last video is directly posted in my profile, wich is public...
Actually I don't use bit nomore, thanks to Grauw's hint.
Now I use JP P,deactivatespritey (I have also deactivatespritex wich is a byte early with a dec hl instruction...
Thank you Santiago! Can you explain better tmp+=x_diff stuff? I'm not sure to understand it
but i feel the force flowing through your algorithm...
Another question: obviously I have to write a collision detection routine (I think it have to be based on sprites coordinates, am I right?). How I can be sure of what hit what when rotating the sprite table? 
The more I go further the more grow problems 
hahaha, yeah, games are not as easy to code as it might seem hahaha. And sure! I can elaborate on the Bresenham-style bullet moving algorithm I was suggesting! Imagine that you have an enemy at coordinates (ex, ey), and the player is at coordinates (px, py). You want the enemy to fire a bullet that goes toward the player. So, the simplest way is to do it like this:
- calculate dx = px-ex, and dy = py-ey, and initalize tmp = 0, and the coordinates of the bullet to bx = ex, by = ey
- Let us now assume abs(dx) > abs(dy) (i.e. that the absolute value of dx is larger than that of dy) (if it is not, then you just have a copy of the code below, but swapping x by y):
- Now, at every game frame you do this:
- if dx > 0 then bx++, else bx--
- tmp += abs(dy)
- if tmp > abs(dx) then tmp -= abs(dy), and if dy > 0 then by++, else by--
And that's pretty much it, the bullet will move in a straight line toward the player. The main idea is this: if abs(dx) > abs(dy), you want to move the bullet one pixel toward the player in the x axis at each game cycle, but you will only move it in the y axis every once in a while. The "tmp" variable controls how often to move it in the y axis. if dy is small, then it will move less often in the y axis, and if dy is large, then the bullet will move more often in the y axis.
This is one of the easiest ways to make objects move at arbitrary angles that I know of. The only small downside is that bullets will appear to move faster if they go in diagonals, than if they go orthogonal to the axis of coordinates. This is how the bullets in XSpelunker are coded (you can see the "updateEnemy_bullet" function in this file for an example: https://github.com/santiontanon/xspelunker/blob/master/src/s... )
If you want all bullets to move at the same speeds, then the easiest way is to resort to the atan2 function I was referring to before, to get the angle at which the bullet has to travel, and then have a table with sin/cos values that will determine the speed in x and y of the bullet for each angle.
Well, often diagonals are higher distances, so fastest bullets are allowed... I'll take a look to the link you send me later, after work. Thank you very much
Opened a youtube channel, so i can share videos that can be viewed by hit9918 too
here's first sprite video, video with sprite deactivation when y<0 or y>191 and vertical scrolling routine
https://youtu.be/7r_DhR8BKdE
scrolling
https://youtu.be/j8BPIKsVBVY
sprites first attempt
https://youtu.be/Wptox9sPWj0
sprites deactivation when y<0 or y>191
If it helps at all to expand on Bresenham, since I have very little else that I might add...
Imagine you were in floating point, and abs(dx) > abs(dy), and dx > 0, you might do something like this:
delta = dy/dx;
current_y = y1;
current_x = x1;
while(current_x != x2) {
++current_x;
current_y += delta;
}
Since, clearly, if you add 'dy/dx' to a number 'dx' times then in total you've added 'dy'. So that's great, but floating point is expensive, so keeping it integer:
delta = dy/dx; // an integer this time, so the real number, rounded down.
remainder = dy%dx; // the remainder from the divide.
current_y = y1;
current_x = x1;
total_error = 0; // see below
while(current_x != x2) {
++current_x;
current_y += delta;
// oh, but whoops, adding 'delta' isn't enough. You've added too little.
// If this were floating point, you should have added delta + (remainder/dx).
// So current_y is now remainder/dx less than it should have been.
// Easy fix: add up the 'fractional' bits, until you find out that current_y is
// now wrong by a whole integer. Then fix it.
current_error += remainder;
if(current_error >= dx) {
// i.e. the number stored in current_y is now a whole integer off from the proper result.
// So transfer that portion of the accumulated error.
++current_y;
current_error -= dx;
}
}
Oh, but, you already know that dx is bigger than dy. So, as an integer, dx/dy is 0. So, actually, get rid of delta:
remainder = dy%dx;
current_y = y1;
current_x = x1;
total_error = 0;
while(current_x != x2) {
++current_x;
current_error += remainder;
if(current_error >= dx) {
++current_y;
current_error -= dx;
}
}
Oh, but wait, by the same token, if dx is bigger than dy, then the remainder calculated via dy%dx is always just dy. So life is even easier:
current_y = y1;
current_x = x1;
total_error = 0;
while(current_x != x2) {
++current_x;
current_error += dy;
if(current_error >= dx) {
++current_y;
current_error -= dx;
}
}
Then after that you just shuffling around which axis is which to ensure that 'dx' really is bigger than 'dy', and to allow for one or the other potentially being negative. That's where the calls to abs() and the other sign tests come into the code above.
The differing bullet speeds come because every time if(current_error >= dx) passes, that bullet gets a bit of extra movement for free in that iteration. So bullets close to diagonal get lots of extra free movement.
Bluffer's tip: if you don't want to move all the way into using fixed point arithmetic then you can adopt another costing approach and get approximately the right answer. It's pretty simple:
In a tick in which the bullet moves only a single pixel on x, it moves a total distance of 1. If it moves a single pixel on x and also moves a single pixel on y, it moves a total distance of sqrt(2) ~= 1.4142, per Pythagoras. So you can use a per-frame algorithm like:
++bullet_motion;
if(bullet_motion >= 0) {
bullet_motion =- do_step(); // which returns 1.0 for a vertical or horizontal step, 1.41 for a diagonal.
}
So as to cause bullets to update less often the closer they are to an exact diagonal. Top tip: actually you should probably do something like:
bullet_motion += 89;
if(bullet_motion >= 0) {
bullet_motion -= do_step(); // which returns 89 for a vertical or horizontal step, 126 for a diagonal.
}
... and not actually do it as a function call like that, obviously. Just build it into your update tick function.
126/89 is approximately 1.42, which is the closest number I could find just now to sqrt(2) within the range where you can use a sign test to decide whether to perform an update tick.
Nice trick at the end of your post to adjust the speed @TomH!! I had not thought of that! Will definitively incorporate it the next time I need to implement this!
...
I don't understand yours explaination here... all those ++, +=, while and braces...
if it's C, or pascal or mathlab or something else, I don't know it...
so if all those stuff means it's equal to, or its greater than, or maybe "you have to add 2 else a baby will cry five houses far from yours"... well tell me the things as they are 
if I can't understand your examples I will not improve myself. I don't want to do a copy/paste from other's code to achieve a result. I wanna understand what I do.
Thanks for your understanding me...
