Alcon 2020 (Slap Fight)

[abalore]

A pesar de que ya existe un port oficial del Slap Fight para CPC me parece que se puede hacer algo mucho mejor, así que me he lanzado a programar uno. Lo estoy haciendo en ensamblador desde cero, sin usar el firmware ni librerías de ningún tipo, incluyendo música y gráficos.

Utilizo interrupciones para la música, el scroll hardware de 1 pixel y el escaneo de los controles. La música la reproduzco a través de un tracker que me estoy haciendo sobre la marcha, que soporta 3 canales más percusión con envolventes de tono y volumen. Los gráficos los hago en el RGAS y luego los paso manualmente a sprites compilados o a un formato de tiles de 4x8 pixels según sea el caso.

Aquí os dejo un vídeo con el progreso actual del juego corriendo a 50 Hz, aunque posiblemente la frecuencia final sea de 25 Hz. El consumo actual de procesador ronda los 9000 microsegundos por frame incluyendo programa principal e interrupciones. Mi estimación es que el consumo final se vaya hasta los 30000 microsegundos con el máximo de enemigos y proyectiles o un boss en pantalla, lo que sería suficiente para correr el juego a 25 Hz sostenidos con comodidad.

En cuanto a la memoria, utilizo un doble buffer que se lleva 32 KB y en los otros 32 KB espero poder meter el programa y un nivel completo. Esta sería la opción multicarga, pero es posible que me decante por usar 128KB y meter los niveles en el segundo banco. Lo ideal sería soportar las dos alternativas para que el juego funcione en un 464.

Aquí está el vídeo:

https://www.youtube.com/watch?v=92rvbrw ... e=youtu.be

Si alguien quiere colaborar lo recibiré con los brazos abiertos. Me vendría bien ayuda en los siguientes temas:

- Composición y programación de la música
- Creación y programación de los efectos sonoros
- Diseño de tiles inspirados en los tiles del juego original
- Diseño de sprites
- Diseño de niveles
- Programación de comportamiento de los enemigos
- Programación de rutinas de colisiones eficientes
- Optimización de rutinas en ensamblador. Hay mucho código susceptible de ser optimizado.

Un abrazo,
Abalore

[6128]

Acabo de ver el vídeo y creo que estás haciendo un trabajo fantástico. Aunque faltan los enemigos y los disparos el scroll es muy suave.

El Slap Fight de CPC no me parece nada del otro mundo pero por lo poco que he visto de tu port hay más feeling de la recreativa original.

[Rhino]

Tiene una pinta estupenda!

[XeNoMoRPH]

Joer , buena música y el scroll super suave , impresionado estoy , gran trabajo

[pinace_es]

El poco trabajo que llevas hecho promete más que el port original de Probe Software. Me encanta el scroll tan suave. Mucho ánimo

[abalore]

Gracias a todos por vuestro apoyo.

He decidido hacerlo exclusivo para 128K, la razón principal es que no quiero renunciar a tener música durante el juego. Además eso me ha permitido introducir unas optimizaciones que han reducido el consumo de procesador a la mitad (de 8569 microsegundos por frame a 4872). La optimización principal consiste en usar un bloque de la memoria extendida como tercer buffer de vídeo para almacenar el background, con lo que no tengo que almacenar el contenido previo de la memoria de vídeo en cada sprite y puedo renderizar el avance del fondo una sola vez y copiarlo a cada frame buffer. Sé que hay otras técnicas reduciendo el número de colores, pero quiero seguir teniendo los 16 colores tanto en el fondo como en los sprites.

Según mis cálculos me queda tiempo de proceso para animar otras 19 naves del mismo tamaño que la mía (12 x 24 pixels de mode 0). Eso se quedará en mucho menos al meter el cropping en los bordes, las colisiones y la IA. Pero aún así espero soportar al menos 12 enemigos en pantalla y de 20 a 30 proyectiles. O un boss de gran tamaño.

En el apartado gráfico he añadido nuevos detalles al mapa. En breve subiré otro vídeo con los avances.

Saludos,
Abalore

[Rhino]

Gracias a todos por vuestro apoyo.

He decidido hacerlo exclusivo para 128K, la razón principal es que no quiero renunciar a tener música durante el juego. Además eso me ha permitido introducir unas optimizaciones que han reducido el consumo de procesador a la mitad (de 8569 microsegundos por frame a 4872). La optimización principal consiste en usar un bloque de la memoria extendida como tercer buffer de vídeo para almacenar el background, con lo que no tengo que almacenar el contenido previo de la memoria de vídeo en cada sprite y puedo renderizar el avance del fondo una sola vez y copiarlo a cada frame buffer. Sé que hay otras técnicas reduciendo el número de colores, pero quiero seguir teniendo los 16 colores tanto en el fondo como en los sprites.

Según mis cálculos me queda tiempo de proceso para animar otras 19 naves del mismo tamaño que la mía (12 x 24 pixels de mode 0). Eso se quedará en mucho menos al meter el cropping en los bordes, las colisiones y la IA. Pero aún así espero soportar al menos 12 enemigos en pantalla y de 20 a 30 proyectiles. O un boss de gran tamaño.

En el apartado gráfico he añadido nuevos detalles al mapa. En breve subiré otro vídeo con los avances.

Saludos,
Abalore

Genial!

Te comento algunas ideas a ver qué te parecen.

* En el video parece que la nave se mueve horizontalmente byte a byte. Si es asi, creo que una mejora para la jugabilidad sería que se pudiera mover a nivel de pixel.

* El clipping con sprites compilados es una putada que a lo mejor te puedes ahorrar. Verticalmente, con el splitscreen del marcador debes estar ocultando 2 o 3 caracteres de alto del area de pantalla del juego, con lo que tienes margen para que los sprites aparezcan por arriba y por abajo como si tuvieran clipping pero sin dibujarlos cortados. Y horizontalmente, con que tu nave y los recorridos de los enemigos no se salgan por los lados ya lo tienes resuelto. El único inconveniente entonces serían los disparos enemigos, pero al ser pequeños y moverse más rápido, puede que no necesiten clipping al fin y al cabo. Si ahorrandote el clipping puedes hacerlo a 50fps estaría de pm.

[abalore]

Te comento algunas ideas a ver qué te parecen.

* En el video parece que la nave se mueve horizontalmente byte a byte. Si es asi, creo que una mejora para la jugabilidad sería que se pudiera mover a nivel de pixel.

* El clipping con sprites compilados es una putada que a lo mejor te puedes ahorrar. Verticalmente, con el splitscreen del marcador debes estar ocultando 2 o 3 caracteres de alto del area de pantalla del juego, con lo que tienes margen para que los sprites aparezcan por arriba y por abajo como si tuvieran clipping pero sin dibujarlos cortados. Y horizontalmente, con que tu nave y los recorridos de los enemigos no se salgan por los lados ya lo tienes resuelto. El único inconveniente entonces serían los disparos enemigos, pero al ser pequeños y moverse más rápido, puede que no necesiten clipping al fin y al cabo. Si ahorrandote el clipping puedes hacerlo a 50fps estaría de pm.

Buena idea lo del movimiento horizontal pixel a pixel. La única manera que se me ocurre de hacerlo es tener 2 sprites para la nave.

Respecto al clipping, desgraciadamente no puedo prescindir del clipping horizontal porque en el juego original muchos enemigos salen de los lados y puede haber explosiones cerca del borde. Lo que había pensado es tener entre 1 y 3 versiones de cada sprite, de forma que si el sprite no necesita clipping (nave, disparos, sidewings) sólo exista un sprite compilado. Y si necesita clipping horizontal o vertical añadir sprites con loops desenrollados que dibujen de arriba a abajo o de lado a lado y meter código automodificable para configurar los puntos de entrada y salida.

[Rhino]

Te comento algunas ideas a ver qué te parecen.

* En el video parece que la nave se mueve horizontalmente byte a byte. Si es asi, creo que una mejora para la jugabilidad sería que se pudiera mover a nivel de pixel.

* El clipping con sprites compilados es una putada que a lo mejor te puedes ahorrar. Verticalmente, con el splitscreen del marcador debes estar ocultando 2 o 3 caracteres de alto del area de pantalla del juego, con lo que tienes margen para que los sprites aparezcan por arriba y por abajo como si tuvieran clipping pero sin dibujarlos cortados. Y horizontalmente, con que tu nave y los recorridos de los enemigos no se salgan por los lados ya lo tienes resuelto. El único inconveniente entonces serían los disparos enemigos, pero al ser pequeños y moverse más rápido, puede que no necesiten clipping al fin y al cabo. Si ahorrandote el clipping puedes hacerlo a 50fps estaría de pm.

Buena idea lo del movimiento horizontal pixel a pixel. La única manera que se me ocurre de hacerlo es tener 2 sprites para la nave.

Respecto al clipping, desgraciadamente no puedo prescindir del clipping horizontal porque en el juego original muchos enemigos salen de los lados y puede haber explosiones cerca del borde. Lo que había pensado es tener entre 1 y 3 versiones de cada sprite, de forma que si el sprite no necesita clipping (nave, disparos, sidewings) sólo exista un sprite compilado. Y si necesita clipping horizontal o vertical añadir sprites con loops desenrollados que dibujen de arriba a abajo o de lado a lado y meter código automodificable para configurar los puntos de entrada y salida.

Si no hay problemas de memoria, parece un buen plan para el clipping. Ten en cuenta tb que al hacer tu nave pixel a pixel, otros sprites relativos a tu nave como los disparos tb necesitarán 2 sprites, aunque estos suelen ser gfxs pequeños. Las explosiones a lo mejor las puedes hacer a nivel de byte y no notarse nada raro, y si haces 2 versiones, puedes aprovechar para que la de pixeles impares sea otra explosion distinta y así dar mas variedad al conjunto.

Por otra parte, ¿por qué estás haciendo tu propio player de musica/sfx pudiendo usar alguno de los que hay por ahí?

Tb te recomiendo que uses una herramienta para sacar los sprites compilados, o a la larga vas a perder mucho tiempo. Si preguntas en foros como cpcwiki o aquí mismo, es posible que alguien ya tenga algo que te haga el trabajo. Sino, a lo mejor te merece la pena hacerte una herramienta propia, ya que el juego tiene bastante sprites, no?

[abalore]

Te comento algunas ideas a ver qué te parecen.

* En el video parece que la nave se mueve horizontalmente byte a byte. Si es asi, creo que una mejora para la jugabilidad sería que se pudiera mover a nivel de pixel.

* El clipping con sprites compilados es una putada que a lo mejor te puedes ahorrar. Verticalmente, con el splitscreen del marcador debes estar ocultando 2 o 3 caracteres de alto del area de pantalla del juego, con lo que tienes margen para que los sprites aparezcan por arriba y por abajo como si tuvieran clipping pero sin dibujarlos cortados. Y horizontalmente, con que tu nave y los recorridos de los enemigos no se salgan por los lados ya lo tienes resuelto. El único inconveniente entonces serían los disparos enemigos, pero al ser pequeños y moverse más rápido, puede que no necesiten clipping al fin y al cabo. Si ahorrandote el clipping puedes hacerlo a 50fps estaría de pm.

Buena idea lo del movimiento horizontal pixel a pixel. La única manera que se me ocurre de hacerlo es tener 2 sprites para la nave.

Respecto al clipping, desgraciadamente no puedo prescindir del clipping horizontal porque en el juego original muchos enemigos salen de los lados y puede haber explosiones cerca del borde. Lo que había pensado es tener entre 1 y 3 versiones de cada sprite, de forma que si el sprite no necesita clipping (nave, disparos, sidewings) sólo exista un sprite compilado. Y si necesita clipping horizontal o vertical añadir sprites con loops desenrollados que dibujen de arriba a abajo o de lado a lado y meter código automodificable para configurar los puntos de entrada y salida.

Si no hay problemas de memoria, parece un buen plan para el clipping. Ten en cuenta tb que al hacer tu nave pixel a pixel, otros sprites relativos a tu nave como los disparos tb necesitarán 2 sprites, aunque estos suelen ser gfxs pequeños. Las explosiones a lo mejor las puedes hacer a nivel de byte y no notarse nada raro, y si haces 2 versiones, puedes aprovechar para que la de pixeles impares sea otra explosion distinta y así dar mas variedad al conjunto.

Por otra parte, ¿por qué estás haciendo tu propio player de musica/sfx pudiendo usar alguno de los que hay por ahí?

Tb te recomiendo que uses una herramienta para sacar los sprites compilados, o a la larga vas a perder mucho tiempo. Si preguntas en foros como cpcwiki o aquí mismo, es posible que alguien ya tenga algo que te haga el trabajo. Sino, a lo mejor te merece la pena hacerte una herramienta propia, ya que el juego tiene bastante sprites, no?

Hola Rhino,

lo de hacer un player de música propio era por pura diversión de ver cómo funcionaba el chip AY. Pero tengo los fuentes del Kitay y estoy pendiente de integrarlo, he visto que tiene una huella de CPU cojonuda (8 - 12 scanlines/frame). Si conoces algún player mejor no dudes en decírmelo.

La banda sonora original del juego no tiene nada parecido a una batería, por lo que he pensado en usar los 3 canales de tono para la música y dejar el generador de ruido para los efectos especiales, con lo que tendría simultaneidad total de la música y los efectos.

Tengo una herramienta propia para compilar sprites, pero tengo que actualizarla porque carga archivos .amsx y ahora estoy usando .rgas.

Como dije en el primer comentario, se aceptan colaboradores. Si alguien se anima le paso los fuentes del proyecto y nos marcamos un calendario en serio.

Un saludo

[Rhino]

Si, el codigo de Madram es muy rápido, el inconveniente es que las músicas ocupan un poco más que con otros players como el Arkos.
Hace tiempo que lo miré, pero si le quieres ganar velocidad a lo mejor puedes hacer PLAYREG de uso de ciclos constante, y llamarla en algún momento donde tengas que sincronizar y estés perdiendo ciclos de CPU con una espera, si es el caso del splitscreen o algún raster que hagas para el marcador, etc...
Si para ahorrar memoria usas solo buffers de #100 (en vez de #400), tb habrá partes del código que te podrías ahorrar.

Me encataría colaborar, pero ya ando con mi propio proyecto. En cualquier caso, para cualquier ayuda técnica o lo que necesites aquí estamos.

Saludos!

[abalore]

Precisamente acabo de integrar el KitAY y va como la seda. Le he hecho unas cuantas modificaciones para invocarlo desde la rutina de interrupción y que utilice el banco de memoria C6 tanto para cargar la música como de buffer de descompresión. Funciona de maravilla, pero tengo una gran duda respecto al buffer de descompresión. ¿Cuántos bytes consecutivos hay que reservar para el buffer? Parece que va rotando por toda la memoria en un tramo de 8 KB. De momento lo tengo apuntando a 8 KB de la memoria superior que no utilizo, pero claro está que esto habrá que mejorarlo.

Lo de hacerlo constante en ciclos de momento no lo necesito, porque el splitscreen, scroll, etc, lo manejo con interrupciones y no tengo ningún loop de espera en ninguna parte.

[Rhino]

Si no recuerdo mal el buffer minimo eran #e00 bytes consecutivos (14*#100), pero eso dependia de como convirtieras la musica a ayc.
En su momento lo toqué bastante, recuerdo que hice que pudiera relocalizar tanto la música como el buffer mientras sonaba. En un metodo de la inicialización se lee si cada buffer es de #100 o #400 y lo tuve que modificar para que llevara la cuenta y saber cuanto tenia que transferir para relocalizar el buffer. Ya te digo, todo esto si no me falla la memoria.

[XeNoMoRPH]

[Artaburu]