ZX-Uno - kit de programación modo Radastaniano

[Haplo]

No funciona el enlace pero creo que entiendo mas o menos a lo que te refieres. ¿y no es más práctico crear unas rutinas de pintado fijas (8x8, 12x10, lo que sea) con las instrucciones "desenrolladas" y exactas para no tirar de bucles?

Y por supuesto, cualquier ayudita por hardware siempre será bienvenida por los sufridos y atormentados "implementadores de juegos"

[mcleod_ideafix]

No funciona el enlace pero creo que entiendo mas o menos a lo que te refieres.

Ahora sí funciona.

¿y no es más práctico crear unas rutinas de pintado fijas (8x8, 12x10, lo que sea) con las instrucciones "desenrolladas" y exactas para no tirar de bucles?

No es la gestión del bucle lo que más consume, sino la gestión de, por ejemplo, las rotaciones, o las máscaras. La idea de los sprites compilados es que todo eso se haga "offscreen" para que a la hora de pintar se vuelquen a memoria los datos ya preprocesados. Que sea o no más práctico que una rutina de pintado para sprites digamos "convencional" depende de muchos factores. Los sprites compilados ganan cuando quieres muchos sprites en pantalla.

Intenta hacer la misma demo, pintando 60 cuadraditos de 2x2, pero con una rutina convencional. En la demo verás que el borde toma varios colores:
AZUL: el tiempo de borrado de los sprites antiguos antes de pintar los nuevos. Esta rutina es también compilada "on the fly". Su tiempo de ejecución es tan corto que probablemente no llegues a ver el color azul en un emulador salvo que lo configures para que te muestre un borde completo.
ROJO: el tiempo de pintado de los sprites. Como ves, todas las bolitas terminan de pintarse antes de que la ULA comience a pintar el paper, con lo que no hay nada de parpadeo. Ese es el objetivo.
MAGENTA: el tiempo de actualización de las posiciones de los sprites. Aquí también se cuenta el tiempo en que se detecta si han chocado con el borde, para cambiar su trayectoria.
VERDE: el tiempo de compilación. Es lo que más tiempo lleva. Se genera el código para pintar los sprites, y también para borrarlos, de acuerdo con las nuevas posiciones que se han calculado en la etapa anterior.
NEGRO: ocioso. La CPU no está haciendo nada, sólo esperar al siguiente retrazo.

Fíjate que el único momento en que se actualiza la pantalla es cuando aún la ULA no la está pintando, con lo que la CPU no sufre contención al acceder a la memoria de pantalla. El resto del tiempo está usando memoria no contenida.

Es posible conseguir mejores tiempos sin necesidad de compilar sprites si usas un 128K y la pantalla shadow.

Y por supuesto, cualquier ayudita por hardware siempre será bienvenida por los sufridos y atormentados "implementadores de juegos"

Dado que Radastan es el padre de la criatura, quisiera saber qué opina él a este respecto. De todas formas te repito que esta ayudita que hemos comentado ahorra un mínimo porcentaje de CPU, en mi opinión. Implementar todo un sprite engine en hardware es factible, pero fuera de las expectativas del modo radastaniano y del ZX-Uno en general. Lo que no quita que alguien lo implemente por su cuenta y lo añada a un "fork" de alguno de los cores.

[radastan]

Y por supuesto, cualquier ayudita por hardware siempre será bienvenida por los sufridos y atormentados "implementadores de juegos"

Dado que Radastan es el padre de la criatura, quisiera saber qué opina él a este respecto. De todas formas te repito que esta ayudita que hemos comentado ahorra un mínimo porcentaje de CPU, en mi opinión. Implementar todo un sprite engine en hardware es factible, pero fuera de las expectativas del modo radastaniano y del ZX-Uno en general. Lo que no quita que alguien lo implemente por su cuenta y lo añada a un "fork" de alguno de los cores.

256x192, 16 colores por pixel, sprites por hardwae... ¡Anda! ¡Una Master System!

¿Entiendes? si ponemos más cosas sale más a cuenta programar directamente en Master System, que también puedes hacerlo con Z88DK y ya hay librerías para dicho sistema. Es absurdo hacer cosas que se salen de lo lógico. Este modo de vídeo tiene una cosa muy buena, y es que se maneja en el mismo espacio de memoria que el ZX Spectrum normal. Es exactamente igual de rápido, lo mismo que hagas en ZX Spectrum puedes hacer en ZXUno con este modo a todo color.

Como mucho tendría sentido un canal DMA, como mucho. Ya que dicho canal podría usarse tanto para cargar más rápido desde MicroSD como para otras funciones en juegos.

[Haplo]

Ya, si eso está claro Radastán, por eso lo he sugerido por si fuera algo trivial y no se salía de madre la cosa. No vamos a reinventar la NES a estas alturas
El reto es que no se pierda el "espíritu spectrum" y queramos o no, el tema gráfico es una de sus principales señas de identidad. Si queremos más virguerías gráficas, como bien dices, programamos para otra plataforma superior que soporte el zxuno y santas pascuas.

Al final todo se reduce a "¿quiero hacer un juego para spectrum o para zxuno?", a partir de ahí empieza el espectáculo

[radastan]

Al final todo se reduce a "¿quiero hacer un juego para spectrum o para zxuno?", a partir de ahí empieza el espectáculo

No, eso es lo mejor. Con la estructura que tiene a nivel gráfico basta cambiar las rutinas gráficas y lo demás queda igual en un juego, el mismo código.

Con el kit que doy, cuando esté plenamente terminado, basta un par de cambios y te despreocupas, programas para ambos a la vez.

[Haplo]

Por cierto, qué editor de textos usáis? Hasta ahora uso notepad++ para todo, pero últimamente he tenido algunos errores extrañísimos al compilar y quizás sea porque no lo tenga bien configurado y se me cuele algún carácter extraño.(y eso que lo he repasado con "mostrar caracteres ocultos")

También he estado buscando estilos para que me resalte el ensamblador de z80, pero no he encontrado nada "apañao".

[mcleod_ideafix]

Por cierto, qué editor de textos usáis? Hasta ahora uso notepad++ para todo, pero últimamente he tenido algunos errores extrañísimos al compilar y quizás sea porque no lo tenga bien configurado y se me cuele algún carácter extraño.(y eso que lo he repasado con "mostrar caracteres ocultos")

También he estado buscando estilos para que me resalte el ensamblador de z80, pero no he encontrado nada "apañao".

Yo uso ConTEXT, que tiene un montón de "highliters" (resaltadores de código), entre ellos, uno exclusivo para Z80.

[Haplo]

Gracias McLeod, he tenido que retocar algunas cosillas del "highliter" para z80, pero está bastante apañao el editor.

Para hacer pruebas, me currado un set de sprites con animaciones y tiles para decorado con el tamaño y paleta adecuado en modo radastaniano... Ahora viene lo divertido, traducir el bmp a una tabla de valores manejable desde zxbasic

Dado que ZX-Paintbrush no soporta este modo, ¿hay que tirar de editor hexadecimal y destripar el .bmp?
¿no hay algo por ahí que haga una conversión a un formato más amistoso?

P.D: El .bmp que tengo es de 120x90 a 16 colores y los gráficos están organizados en cuadrículas de 10 pixels de alto x 12 de ancho.

[mcleod_ideafix]

Dado que ZX-Paintbrush no soporta este modo, ¿hay que tirar de editor hexadecimal y destripar el .bmp?
¿no hay algo por ahí que haga una conversión a un formato más amistoso?

P.D: El .bmp que tengo es de 120x90 a 16 colores y los gráficos están organizados en cuadrículas de 10 pixels de alto x 12 de ancho.

La cosa es que un BMP a 16 colores, excepto la información de la paleta en sí, ya está en el formato de pantalla del modo radastaniano. Bueno, casi: los BMP se guardan desde la última línea a la primera, pero dentro de cada línea, los píxeles se guardan en el mismo formato: 4 bits para el pixel izquierdo de un par, y los otos 4 para el pixel derecho.

De hecho, el visor de videos en formato radastaniano lo que hace es descodificar bloques de bytes que han sido convertidos desde la ristra de BMP's. Mira el código fuente del fichero makevideoradas.c para ver cómo se convierte un BMP a una pantalla usable desde el modo radastaniano.

[Haplo]

Gracias por la info, me ha resultado muy útil, pero como soy muy bruto he tirado de apaño de albañil :

-Voltear horizontalmente la imagen con el editor de imagen (paintshop pro por ejemplo)
-Editar el .bmp con un editor hexadecimal y quitarle los primeros 118 bytes.
-guardarlo como "xxx.bin"
-Añadir el fichero resultante al código con "incbin xxx.bin"

Luego es cuestión de calcular el offset de los gráficos según las dimensiones y adaptar la rutina de impresión.

Como no podía ser todo tan fácil, me he estado divirtiendo con la paleta, al final he conseguido más o menos poner de acuerdo a todos los editores gráficos que utilizo y aunque de forma artesanal, la cosa funciona.

Lo que no acabo de comprender es porqué el color #15 de la paleta es ignorado, es decir, ponga el valor que ponga, me sale siempre un color violeta...
Quiero recordar el "border" coge su color de ahí precisamente, pero me resulta extraño que no se pueda cambiar ¿hago algo mal o es una limitación de este modo?