Veamos. El tema clave está en la pregunta "¿en cuántos pasos quieres que el disparo recorra su camino?". Lo mejor sería moverlo en un número de pasos que fuese potencia de dos, ya que como el Z80 no permite dividir fácilmente por otros números ya empezaríamos a liarla parda.

Partamos del hecho de que tienes un incremento IX y otro incremento IY (no confundir con los registros de igual nombre que pululan por el Z80). Supongamos, además, que quieres hacer 2^k pasos, por lo que tienes que dividir entre 2^k, lo que equivale a desplazar k veces hacia la derecha. Bien, la idea sería en cada uno de los 2^k pasos sumar el incremento (para cada coordenada) dividido por 2^K, con lo que al final del proceso el resultado será que se ha sumado el incremento total y el disparo llega a su destino.

¿Cómo tratar los decimales en el Z80? Con números de 16 bits. Pensemos que un número de 16 bits puede ser visto como un valor entre 0 y 65535 si lo vemos como un número entero, pero si pensamos que está formado por 8 bits de parte entera y 8 bits de parte decimal (8.8 para abreviar), entonces podremos representar un número entre 0 y 255+255/256. Realmente ambos casos son iguales, simplemente el segundo equivale a dividir por 256 el primero, nada más.

Así pues el procedimiento sería (pongo partes en pseudocódigo ya que ahora voy algo justo de tiempo):


así hl (visto como decimal 8. contendría el incremento


obteniendo así el incremento dividido por 2^k en hl


guardando el incremento en una variable en memoria que representa un valor 8.8


lo mismo para la coordenada inicial


que la guardamos en una variable en memoria que también ha de ser vista como un valor 8.8. Con esto ya tenemos la inicialización completa (obviamente calcularemos incremento y coordenada inicial para cada dimensión). Luego, a cada paso:


y ya tenemos la coordenada actual actualizada (valga la redundancia). Como el Z80 almacena siempre primero el byte de menor peso, nos bastaría con acceder al contenido de coordenadaactual+1 para saber la parte entera de la coordenada actual, que es el valor que hay que poner en la coordenada del sprite.

Espero que esta explicación pueda despejar tus dudas. Obviamente esto puede extenderse y trabajar con números 4.4 que caben en un byte, o incluso con números 3.5, 13.3, etc. Todo un mundo de posibilidades que dependen de cómo miremos los números.

Un saludo
--
Sph.

No, no te vale. ¿Por qué? Imagina que y=y0 (un desplazamiento horizontal puro), el incremento de X sería 0 y no se movería. Peor aún, imagina que x=x0 (un desplazamiento vertical puro), no podrías calcular el incremento de x porque intentarías dividir por cero.

Tú propones calcular la pendiente de la recta que une ambos puntos, mientras que mi propuesta va por expresar la recta en coordenadas paramétricas (échale un vistazo a http://es.wikipedia.org/wiki/Curva_param%C3%A9trica aunque no hablan de rectas explícitamente). Mi propuesta es tomar esa recta, dividirla en un número N de segmentos (N=2^k) y en cada paso mover el sprite a cada uno de los segmentos. Esto significa que la velocidad del sprite siempre va a depender de la longitud de la recta, ya que para rectas grandes se moverá más rápido que para rectas pequeñas, pero siempre puedes ajustar k (N, por tanto) para cada trayectoria.

Puntualizo.

Cuando compruebo que sea menor de $20, lo hago porque tengo montado el byte de tal forma que los 4 bits mas bajos son los decimales y los 4 mas altos son los enteros.

Con esto hago la aproximacion.

Tengo que puntualizar que solo lo he probado cuando ambos son positivos.

Veremos cuando acabe la rutina si funciona para positivos y negativos.