CPCtelera, desarrollar juegos para Amstrad de forma sencilla

[corpiano]

Hola.

Todavía no he probado la cpctelera y hablo sin conocimiento, pero a bote pronto me vienen a la cabeza 2 preguntas:

1. En el vídeo de ejemplo se puede ver como un fondo más o menos "cuadrado" en tiempo de diseño se "aplasta" al ejecutar el juego en modo 0. ¿Se puede utilizar alguna herramienta como Sprot o RGAS que permita trabajar diseñando imágenes directamente en modo 0?

2. Ya tuve quebraderos de cabeza utilizando la librería CPCRSLIB para mover un sprite de izquierda a derecha con precisión de 1 pixel en modo 0. En los ejemplos de la cpctelera que he visto parece que la precisión del movimiento en modo 0 es de 1 byte (2 pixels). ¿Estoy en lo cierto o me equivoco?


Estaría genial que una charla de un certamen retro se centrara en la creación de un videojuego en vivo y en directo para CPC utilizando la cpctelera. Ese día probablemente llegará, pero por favor, pido encarecidamente que ese día algún alma caritativa tenga una webcam o similar para que podamos verlo desde casa (y rebobinar las veces necesarias).

Un saludo muy fuerte desde málaga!!!

[ronaldo]

Buenas preguntas, @corpiano . Te contesto:

• CPCtelera incluye las últimas versiones de RGAS e Img2CPC como herramientas de diseño. Con ambas puedes crear imágenes para cualquier modo, incluyendo modo 0, por supuesto. De hecho, en esta versión puedes crear imagenes con Gimp o Photoshop y pasarlas a tiles / sprites de forma automatizada con cpct_img2tileset. También puedes crear mapas de tiles con Tiled, exportarlos a CSV y utilizarlos directamente en tú código.
• La versión actual de CPCtelera no tiene soporte directo (a nivel de API) para sprites con precisión al pixel, aunque está en la lista de tareas para próximas versiones. Sin embargo, tienes un ejemplo de cómo puedes implementarlo en C incluido en la carpeta examples/advanced/move1pixel. Este ejemplo está incluído en la última actualización del github y va a estar incluido en la bugfix release que voy a sacar hoy .

Aquí tienes un vídeo que muestra el ejemplo que te digo en movimiento:


Muy probablemente haremos un taller de programación de videojuegos con CPCtelera este año en Retroconsolas Alicante. Conforme se acerque la fecha lo iremos anunciando. Por supuesto, trataremos de grabarlo y transmitirlo en Videostreaming en directo, como el año pasado .

De todas formas, mientras tanto, te animo a descargártela y probar. Tienes toda la documentación online y viene con un montón de ejemplos de código. Además, aquí siempre estamos para echarte una mano con lo que necesites .

[corpiano]

Hola.

Gracias por tus respuestas. En el ejemplo de precisión de 1 pixel veo que el quid de la cuestión está en la función shiftSprite. A nivel de C yo también utilicé hace tiempo una función de rotación dinámica de sprites para CPCRSLIB (de hecho, está implementada en el ejemplo http://amstrad.es/forum/download/file.php?id=2988). Supongo que la mía está menos optimizada pero básicamente el concepto de rotación de sprites es el mismo.

Respecto a la librería, no la voy a usar por ahora. El tiempo que tengo disponible está totalmente dedicado a un juego que tengo que entregar antes de final de Octubre.

[ronaldo]

Sí, así es. El quid de la cuestión es mover los bytes de los sprites para ocupar las posiciones impares. Se puede hacer de formas más o menos optimizadas, pero la tarea es esa. En última instancia puedes tener 2 copias del sprite: una en posición par y otra en posición impar. Ocupa mucha memoria, pero sería lo más rápido. Realmente la tuya no tiene porqué estar más o menos optimizada: hacerlo en C sin esforzarse mucho es bastante lento de por sí (comparado con una buena rutina optimizada en ensamblador) .

Sin problema . CPCtelera está ahí para cuando cada cual quiera y le apetezca. Como curiosidad, hay gente usandola como sistema de build, sin utilizar lo que es propiamente la librería. Incluso una persona está usando CPCRSLib como librería y CPCtelera como sistema de compilación .

Si en un futuro la pruebas, pásate y nos cuentas las dudas, ideas y sugerencias que te vengan, que siempre será muy útil .

Suerte con tu juego. A ver si este año consigues un resultado igual o mejor que el año pasado en el CPCRetroDev

[KaosOverride]

Chachi, he logrado lanzar el Img2CPC.exe y el RGAS.exe que estan hechos en .NET gracias a MONO en la raspberry

He tenido que instalar todo esto de MONO

sudo apt-get install mono-runtime libmono2.0-cil libmono-winforms2.0-cil mono-vbnc

[ronaldo]

Gracias a Augusto Ruiz acabamos de sacar la release 1.2.2 de CPCtelera integrando una nueva versión de Img2CPC reescrita entera en C++, y que corre código nativo en todas las plataformas (incluída la Raspberry Pi). Se puede seguir utilizando cómodamente a través del script cpct_img2tileset .

Espero que os guste!

[KaosOverride]

Mola, asi menos peso para MONO, Ya solo falta el RGAS

[ronaldo]

Ese estará más complicado que lo veas en nativo. De todas formas, es mucho más cómodo en Raspberry hacer gráficos con gimp en 1 fichero y convertirlos de un plumazo con cpct_img2tileset

[ronaldo]

Acabamos de sacar la release 1.2.3 de CPCtelera. Esta es una release crítica y os recomiendo encarecidamente actualizar.

• Release 1.2.3 de CPCtelera en ZIP.
• Notas de Release 1.2.3 (Inglés)

Detalles:
El motivo principal es que hemos descubierto otra reproducción del bug de optimización de llamadas de cola de SDCC, que sucede con funciones que utilizan convención __z88dk_callee y parámetros impares en número de bytes. Cuando el bug sucede, el programa retorna a puntos aleatorios, por lo la máquina se cuelga o reinicia.

Hace unas semanas ya corregimos y corregimos una primera primera ocurrencia de este bug, en todas las funciones __z88dk_callee con parámetros. La release 1.2 de CPCtelera ya incluía un fix para este bug.

Para esta segunda ocurrencia del bug, contamos con un fix oficial de los desarrolladores de SDCC, que podéis encontrar en su repositorio en el commit 9293 (del pasado 10 de agosto). El fix oficial cubre ambos casos y también corrige otro bug encontrado sobre desplazamientos variables a la izquierda. Hemos importando esta solución y la versión de SDCC incluída en CPCtelera ya cuenta con ella.

Nota importante para usuarios de SDCC:
Si usáis SDCC sin CPCtelera, os recomendamos encarecidamente que os bajéis el último snapshot disponible y NO utilicéis la release 3.5.0. Estos bugs que han corregido son bastante complicados de detectar y pueden costaros muchas horas de desarrollo. Es preferible estar actualizado.

Otros detalles:
Para quienes queráis testear, en los últimos commits del repositorio hemos incluído la conversión automática de ficheros binarios a arrays de C. Esto hace que todos los ficheros .bin puestos en src/ se conviertan automáticamente y compilen junto con el proyecto, pudiendo hacer uso inmediato de ellos en vuestros programas.

Esta funcionalidad ha salido del debate reciente en este hilo. Gracias a @na_th_an y @Artaburu por plantear las dudas y aportar las ideas que han llevado a esta funcionalidad .

[Artaburu]

Muchas gracias por el soplo, bajando versión corregida.

Lo que no tenía ni idea es lo del callee de z88dk, es nuevo en SDCC? Lo había visto el otro día mientras miraba la CPCTelera pero se me olvidó comentarte.

[ronaldo]

Sí, SDCC 3.5.0 incluyó __z88dk_callee y __z88dk_fastcall como nuevas convenciones de llamada. Es parte de su esfuerzo de integración con Z88DK.

Las dos convenciones de llamada son muy útiles para la mejora del rendimiento en general. He cambiado la mayoría de las rutinas de CPCtelera a una de las 2 convenciones de llamada ganando ciclos y bytes de memoria (si echas un ojo a los commits previos a la 1.2. podrás ver los cambios). Os recomiendo mucho que les echéis un ojo porque merecen la pena.

Lo que sucede, claro, es que no lo han testeado demasiado. Nada más cambiar a __z88dk_callee apareció el bug de las llamadas de cola (tail jumping). Es una optimización que hace el compilador sustituyendo código como este:

Código: Seleccionar todo

mifuncion:
....
call otrafuncion
ret

por este,

Código: Seleccionar todo

mifuncion:
...
jp otrafuncion

De modo que 'otrafuncion' vuelve directamente al quien llamó a 'mifuncion' aprovechando la dirección de retorno que está ya en la pila. Esto funciona siempre que 'otrafuncion' no tenga parámetros, pero esto último no lo tuvieron en cuenta en SDCC 3.5.0. Por eso, en SDCC 3.5.0, esta optimización hace cascar al programa: 'otrafuncion' espera que los primeros 2 bytes de la pila sean la dirección de retorno, pero se encuentra un parámetro en su lugar, haciendo que todo explote.

Este bug puede no aparecer nunca, si no se da la casualidad de llamar a una función __z88dk_callee como última acción dentro de otra función. Por eso, se ve que no lo tenían muy probado.

En el último snapshot esto está bien corregido. Hasta ahora lo hemos arreglado con un par de parches prácticos, pero ya tenemos un fix bueno.

[Artaburu]

Estupendo porque yo lo echaba de menos de z88dk, pasar un parámetro en HL en lugar de en la pila.
Como bien dices, se ahorran muchos bytes y ciclos y en alguna función puede suponer hasta más trabajo buscar el parámetro que hacer la acción.

[ronaldo]

Sin duda, lo de pasar un parámetro en HL (o L o DE:HL, según el tamaño) es una bendición en muchos casos. El __z88dk_callee también es muy buena opción en general y, por lo que he visto en código, es habitual en Z88DK.

La opción genérica de introducir los parámetros en la pila, esperar que la función deje la pila en el mismo estado, y retirarlos al volver, me parece muy mala en cuanto a rendimiento en general, por lo menos en el Z80. Es muy standard, eso sí, pero cuando hablamos de rendimiento es un poco dolorosa.

[MiguelSky]

Vaya, al intentar instalar la versión nueva:

device/lib/ds400/Makefile
config.status: error: cannot find input file: `src/z80/Makefile.in'
!!ERROR!!: SDCC was not adequately configured for some reason.
Makefile:42: fallo en las instrucciones para el objetivo

[ronaldo]

@MiguelSky: Estoy haciendo pruebas de instalación y, por el momento, no puedo reproducir el problema. He probado a instalar la release 1.2.3 y la última versión del repositorio limpias en Linux y Windows XP/Cygwin y me compilan perfectamente.

Dame algún dato más: ¿Es la 1.2.3 descargada en zip o es del repositorio? ¿La instalas ejecutando el setup.sh? ¿Actualizas reinstalando de 0 o sobre una versión que tenías ya instalada? ¿En qué sistema operativo? Si es Windows/Cygwin, ¿Cygwin 32 o 64? ¿Hace mucho que tienes instalado Cygwin? ¿Has probado a actualizarlo? ¿Si instalas la 1.2 o la 1.2.2 te pasa lo mismo?

Ahora mismo no tengo idea de qué puede estar provocando el fallo concretamente. El fallo que te da es como si el configure de la instalación de SDCC no hubiera funcionado bien, y no hubiera creado el Makefile.in que se usa después para compilar. El tema es que no puedo reproducir el fallo .