Asteroids: movimiento de los sprites por toda la pantalla (paso III) #Programación retro del Commodore 64

Los disparos no son sprites, son caracteres. Por tanto, no hace falta nada especial para moverlos o pintarlos por toda la pantalla. Llega con que su coordenada X tome valores entre 0 y 39 (40 columnas) y su coordenada Y entre 0 y 24 (25 filas).

Ahora bien, dado que los disparos nacen en la posición de la nave cuando se produce el tiro, y dado que la nave ha estado confinada a la zona X <= 255 hasta hace pocas entradas, sí se hacen necesarias algunas revisiones.

Concretamente:

  • La rutina "pixel2Char", que sirve para determinar la posición inicial del disparo a partir de la posición de la nave, hay que ampliarla para que la coordenada X tome dos bytes ("pixelXLo" y "pixelXHi"). Esto ya lo mencionamos en la entrada anterior.
  • En la rutina "creaDisparo" teníamos una verificación de límites para evitar que los disparos nacieran fuera de la zona permitida, y borraran caracteres del texto impreso en pantalla. Habrá que revisar esos límites.
  • Por último, en la rutina "actualizaDisparos" movíamos los disparos, y también teníamos una verificación de límites para que estos desaparecieran al llegar a los bordes de la pantalla. Habrá que revisar estos límites también.

Los dos últimos puntos son muy sencillos, básicamente hay que cambiar un X < 31 (columna 31) por un X < 40 (columna 40). Sin embargo, el primer punto requiere algo más de explicación.

Las fórmulas matemáticas que veníamos utilizando para pasar de pixels a caracteres era las siguientes:

  • charX = (pixelX – 24) / 8 + 1
  • charY = (pixelY – 50) / 8 + 1

Es posible que hayáis visto otras fórmulas parecidas, pero algo distintas, en algunas versiones intermedias del proyecto. No son más que intentos de ajustar un poco más las fórmulas, ya que la falta de resolución en los caracteres (se mueven de 8 en 8 pixels) hace que los disparos no siempre estén 100% centrados respecto a la nave que, al ser un sprite, sí puede moverse pixel a pixel.

En cualquier caso, independientemente de la fórmula precisa que estemos usando, lo importante es que ahora pixelX ya no es un byte, sino dos. No sería difícil desarrollar una nueva fórmula matemática, pero ni siquiera hace falta.

El byte pixelXHi sólo puede tomar los valores 0 y 1:

  • Si toma el valor 0, la nave está en la zona izquierda de la pantalla, y las fórmulas de aplicación son las de siempre.
  • Si toma el valor 1, la nave está en la zona derecha de la pantalla (X >= 256). En esta zona ya sólo el byte Hi aporta (256 – 24) / 8 = 29 columnas. Y a partir de ahí, todas las columnas extra que aporte el byte Lo…

En definitiva, podemos hacer una nueva rutina "pixel2Char" con dos ramas, igual que hicimos con "posicionaSprite" o "verificaLimitesXJugador":

Asteroids - Pixel2Char nueva

Es decir:

  • Para obtener charY aplicamos la fórmula ya conocida.
  • Y para obtener charX aplicamos una fórmula u otra dependiendo de que la nave esté en la zona izquierda de la pantalla (etiqueta "p2cNoHi") o en la zona derecha (etiqueta "p2cSiHi").

Bueno, con esto ya hemos ajustado la nave y los disparos. Sólo nos quedan los asteroides. Ánimo, que ya queda no queda nada…

🙂


Código del proyecto: Asteroids18


Editar

Josepzin

No hay comentarios:

Publicar un comentario