Taller de programación video-juego. Nivel 1.

[afx]

Está claro que a programar se aprende programando, y más en el terreno de los video – juegos. Aunque hayas desarrollado programas (por ejemplo de gestión, como es mi caso) el tema de los juegos es otra cosa diferente, tienes que tratar con aspectos nuevos relacionado con los gráficos, control de teclado, velocidad de pintado, fluidez de los movimiento, …

Bueno, este rollo introductorio no es más que para proponer otro pequeño “programilla” de juegos para el QL a modo de “taller de programación de video-juegos, nivel 1”. En este caso el “nada original” y clásico juegos tipo “rompemuros”. He empezado el fin de semana pasado a escribir algo de código en superbasic y, por muy sencillo que parezca el problema, la cosa se lía un poco cuando tratas con velocidad en la máquina real, control de tiempo, gráficos, etc…

Bien, la propuesta de este hilo es tomar un ejemplo de juego muy simple para ver si gente como yo (y quien quiera colaborar) somos capaces de construir un juego tipo arcade en una máquina retro (en este caso el QL) con las enseñanzas y orientaciones de algunos de ustedes (¡¡yo soy el alumno del taller ehh !! ). Al menos ir aprendiendo durante el proceso (insisto, no hay otra forma de aprender a programar si no es programando, pues a eso vamos ….).

Le he mandado a badaman una maqueta muy primitiva del juego a ver si lo cuelga en algún sitio para hacer referencia en este foro. La velocidad en la máquina real con superbasic interpretado es bastante mala, pero compilado con Qliberator la cosa empieza a ser jugable. La maqueta está aún en modo texto, pero el código está más o menos parametrizado para adaptarlo a modo 8, modo 4 (o los dos), diferentes tamaños y localización de zonas de juego, etc… El tema gráfico como dije, ahora es patéticamente pobre, pero sólo pretendía valorar la viabilidad de hacer dicho juego.

Propongo este juego concreto porque: por un lado es muy fácil la programación de la estrategia del juego y por otro lado porque creo que no requiere mucha “caña” gráfica. (Esto es fundamental para los que no tenemos mucho tiempo libre y además estamos empezando en esto de los video-juego --mejor empezar por algo poco ambicioso--).

Por proponer algo creo que haría falta diseñar una imagen "a-ladrillada" de un tamaño concreto (con ladrillos de 18x10 pixels por ejemplo), luego el juego iría destruyendo ese muro "a cachitos" (pintando arriba bloques del color de fondo). Si se enfoca así y alguien se anima a hacer esa imágen sería simple de terminar el programa, (si no tal vez no merezca la pena completarlo). El tema crítico es conseguir el movimiento fluido de la pelota y de la barra inferior. Badaman me sugirió utilizar caracteres (cosa que hice al principio) pero me parecía que los movimientos eran poco fluidos. Tal vez esto esté pidiendo a gritos esas rutinas para menejo de sprites (no lo sé).

Bueno, ¿cómo lo ven?, ¿alguien se anima?.

[radastan]

Yo me animo con los gráficos en modo 256x256, lo pide a gritos.

Estoy a medio camino de terminar la rutina de ensamblador para sprites simples, partiremos de ahí para poner gráficos decentes.

[badaman]

El enlace al juego, sn su versión para Qlay2, y que puede usarse tambien en otros emuladores.

http://sinclairql.es/progs/juegos/rm_Qlay_WIN3.zip

o lo que es lo mismo:

http://www.speccy.org/sinclairql/progs/ ... y_WIN3.zip

Tengo que preparar una nueva versión de uQLx pues con la actualización a Ubuntu 8.04 me ha dejado de funcionar.

[afx]

Yo me animo con los gráficos en modo 256x256, lo pide a gritos.
Estoy a medio camino de terminar la rutina de ensamblador para sprites simples, partiremos de ahí para poner gráficos decentes.

Esto empieza bien ... ..., con esas aportaciones ya hay más de medio juego encaminado...

Yo continuaré entonces con la parte general del juego (estrategia, niveles, vidas, ...). Para ir empezando, y siguiendo algunos consejos de badaman, los siguientes podrían ser algunos planteamientos iniciales:
- El juego será sólo en modo 8 (256x256).
- Habrá un panel principal de unos 360 pixels por 200 que es la zona principal de juego, a su derecha tres paneles pequeños unos debajo de otros con distinta información. Contendrán: 1) puntuación de la partida y "record" de juego; 2) nivel, vidas restantes y tiempo invertido y; 3) zona de opciones, pequeño menú o otra info.
- Habrá un margen alrededor de todos esos paneles y otro margen más pequeño entre ellos.
- Se podría usar el font digital que nos pasó badaman en otro post.
- El juego podría tener varios niveles (con dificultad creciente, más ladrillos y más velocidad) y varias "vidas" por cada nivel (4 por ejemplo).

Espero avanzar algo estos días y poner una propuesta para irla comentando.

Saludos.

[radastan]

[
- El juego será sólo en modo 8 (256x256).
- Habrá un panel principal de unos 360 pixels por 200 que es la zona principal de juego

¿Mande? ¿Cómo piensas meter un área de juego mayor que la resolución de pantalla?

[afx]

¿Mande? ¿Cómo piensas meter un área de juego mayor que la resolución de pantalla?

Esto del modo 8 (o lo que se "dice" que es equivalente, 256x256) es confuso.

Con las pruebas que he realizado, creo que aunque estemos trabajando en modo 8, las instrucciones que abren canales de pantalla (o consola), en este caso la ventana para la zona de juego, hay que definirlas en términos de pixels en una matriz de 512x256. Por ejemplo las instrucciones del superbasic OPEN "scr_xxx", WINDOW, CURSOR, BLOCK, aunque estemos en modo 8, trabajan en pixels "reales" (en 512x256). Las otras instruccions gráficas (LINE, CIRCLE, ...) lo hacen en coordenadas relativas a la escala (SCALE) definida por el usuario (por defecto 100 en el eje vertical).

Por ejemplo:

Código: Seleccionar todo

100 MODE 8 
110 OPEN #4, scr_360x220a25x15
120 CLS #4
130 CURSOR #4, 340,10
140 INK #4, 5
150 PRINT #4,"X"
...

((La cadena "scr_" de la línea 110 indica "pixels_ancho" x "pixels_alto" a "posX" x "posY"))

Este código dibujaría el panel de juego tal como lo tengo pensado y pone una X en color azul (color que no existe en modo 4) en la parte derecha superior de la zona de juego.

Si en lugar de la línea 110 del código anterior, hubiéramos puesto

Código: Seleccionar todo

110 OPEN #4, scr_200x220a15x15

.. cosa que parece más lógica, ya que si hay 256 pixels de ancho, estamos diciendo que queremos definir una ventana de 200 pixels de ancho.

Pues bien, esta última línea, a pesar que estamos en modo 8, sólo crea una ventana de menos de media pantalla de acho.

Yo concluyo por estas pruebas que aunque estemos en modo 8 (256x256, término que me parece confuso) muchas instrucciones del superbasic para tratamiento de gráficos trabajan a 512x256. Lo único que veo que cambia en modo 8 son el tamaño del juego de caracteres y el número de colores. Además creo que la imagen que hay que fabricar para ponerla en esa zona del juego debe ser justo de 360 pixels reales de ancho.

Algunas pruebas más:
He cogido la imagen "dragon_scr" que hiciste para OSUSQ, y que badaman me mando convertida para el QL y cuando la muestro en modo 8 o en modo 4 la imagen se ve exactamente del mismo tamaño. La única diferencia es que en modo 8, hay pixles (los blancos y los verdes) que hacen una especie de flash barrido hacia la derecha (supongo que debido a la paleta de colores o algo asi). Pero como te digo, el tamaño de la imagen en pantalla es exactamente igual ( )

Todo esto es confuso, a ver si hay alguien más que nos aclare el tema de forma "científica". Yo ahora tengo un lio con este tema, pero lo que sí es cierto es el código SuperBasic que te he comentado.

[badaman]

A efectos de pixels "reales" lo que se dice pixels definidos en la memoria de video, el modo de baja resolucion (conocido como modo 8 o modo 256) guarda una relación con el modo de alta resolución (conocido como modo 4 o modo 512) que puede definirse como de exactamente la mitad de ancho.

Es la mitad en pixels, pero también es la mitad en bits de definición de pixels. Por eso una pantalla en modo 512 ocuipa igual que una pantalla en modo 256. Hay el doble de pixels pero ocupan la mitad de espacio cada uno.

Donde mejor se ve todo esto es en el ancho de los caracteres. En el modo de alta los caracteres son mas estrechos que en el de baja pese a estar definidos identicamente.

Por la forma en que están definidos los pixels, si cambiamos de modo, una imagen como la del dragón ocupará el mismo área de pantalla, ya que ocupa los mismos bytes, pero su definición no será la misma. Si no existiese el parpadeo se vería claramente como la imagen en modo 256 pierde detalle. Los pixels son exactamente el doble de anchos que en el modo 512.

Según esto último, es posible ver imágenes de baja resolución en el modo de alta resolución, pero no al revés (a menos que desactivemos el flash en todos los pixels de pantalla). Si usamos el poke que indicaba en otro hilo acerca del cambio de modo, es facil comprobarlo cargando una imagen en baja resolución y haciendo poke para cambiar el modo a modo de alta resolución. Los colores azul, magenta, cian y amarillo se verán tramados en respectivos colores negro, rojo, verde y blanco.

A efectos de cambio de modos de pantalla, la definiciones de ventanas son iguales. Se definen relativas a 512x256, pero una vez definidas, dependiendo del modo de pantalla podemos dibujar pixels mas o menos finos.

Asi pues, independientemente de la definición de ventanas, si dibujamos imágenes para modo 512 o para 256, tendremos que pensar que las del modo de alta resolución tienen el doble de resolución.

Caso a parte es el tema de scalas, que no afectan para nada a los sprites que dibujan directamente en pantalla.

A efectos del juego, podríamos hablar de pixels de pantalla directamente. Creo que eso liará menos, ya que los parámetros de las definiciones de pantalla no sirven más que para eso.

En el caso que indica afx, a la hora de definir la ventana, usará 360x200 pixels, pero en el modo de baja resolución, realmente está usando 180x200 pixels.

[radastan]

AFX, el problema es uno de tantos de las prisas por sacar el QL, simplemente por pereza (y no por otra razón) el cálculo de los pixels de pantalla se hace por medios bytes. Es decir, en un byte el modo de 256x256 almacena 2 pixels, y en el modo de 512x256 almacena 4 pixels. En su perrera total, la rutina de la ROM ni varía los parámetros si estás en un modo u otro para el cálculo de las ventanas y por eso tienes que multiplicar por dos todos los valores en el modo de 256x256.

Lo dicho, que no es nada oscuro ni enigmático, es otro de los tantos fallos de la ROM original. Todo esto será cosa del pasado con las rutinas que voy a sacar (bendito lenguaje ensamblador).

[badaman]

AFX, el problema es uno de tantos de las prisas por sacar el QL

No se trata de un fallo Radastán, sino de una feature

No, en serio. la distribución de pantalla está pensada para poder emplear las mismas imagenes en ambos modos de pantalla. Fijte que, en ambos modos, los bits que corresponden al color rojo y al color verde estan justo en las mismas posiciones, lo que permite, hipotenticamente, pasar de un modo a otro mostrando una apariencia analoga.

Lo de los bugs del Ql va por otro lado y son mucho mas mundanos, como por ejemplo que en la versión MGE cada pixel dibujado con POINT se vea doble y cosas por el estilo.

Los miticos fallos del S.O. de los que se hablan en muchos atículos corresponden a la primera versión de la ROM de QL, la que incorporaba el SuperBASIC en una ROM enchufable. De esos sistemas ya no queda ni rastro, y en la siguiente versión fueron arreglados todos los problemas.

Precisamente el que no se explicase bien en su momento todo esto fue uno de los motivos por los que el QL tenía mala fama.

[radastan]

No se trata de un fallo Radastán, sino de una feature

No, en serio. la distribución de pantalla está pensada para poder emplear las mismas imagenes en ambos modos de pantalla. Fijte que, en ambos modos, los bits que corresponden al color rojo y al color verde estan justo en las mismas posiciones, lo que permite, hipotenticamente, pasar de un modo a otro mostrando una apariencia analoga.

Lo ógico sería para emplear el mismo código en un modo u otro, pero es que no veo mucha utilidad a eso. La única razón que puedo pensar es que los programas escritos en SuperBasic se vieran igual en monitor y en TV (recordemos que en modo TV se pone en modo 256x256 por defecto).

Por cierto, si nos da por cambiar el OSUSQ al modo 256x256 manteniendo todo igual... ¿qué sucede?

[badaman]

Piensa en la multitarea.

Perfectamente podemos trabajar con programas en modo 8 y modo 4 compartiendo la pantalla. Al pasar de uno a otro modo, sin resetear la pantalla, ls imagenes deben verse al menos parecidas mientras se ejecuta otra aplicación.

Esto es mucho más comprensible bajo un entorno de ventanas, pero no se le ha sacado mucho partido.

Hay otra ventaja a la hora de trabajar con la estructura de la memoria de pantalla tal cual está definida, y es la de afectar a un conjunto de pixels amplio de una vez realizando operaciones de 16 bits.

si tenemos el OSUSQ en pantalla y de pronto cambiamos a modo de baja resolución con un poke se llenara toda la pantalla de parpadeos. Previamente debemos desactivar todos los bits de flash y blue (lo que podemos hacer si de cada 2 pixels repetimos el primero 2 de ellos)

[afx]

"Güeno ...." parece que se me van aclarando las cosas.

La parte buena de todo esto es que tal vez el código sea más portable entre modo 8 y modo 4 con SuperBasic de lo que yo pensaba.

Por ejemplo:

Código: Seleccionar todo

100 OPEN #3, scr_512x256a0x0
110 CURSOR #3,256,128: PRINT #3, "x"

Imprime una x en el centro de la pantalla independientemente del modo, la única diferencia es el tamaño del carácter.

Si en la línea 110 sumamos un pixel en el eje X (257) en modo 4 efectivamente el carácter se desplaza un pixel a la derecha, pero en modo 8 el carácter se imprime en el mismo sitio. En modo 8 hay que ir sumando de 2 en 2 unidades en el eje X para ir desplazando el carácter un "pixel" ("pixel" de modo a la derecha. (( Lección aprendida ...: el pixel del modo 8 es el doble de ancho pero hay que sumar dos unidades al eje x para rodarlo un "pixel-m8" a la derecha en instrucciones como CURSOR, BLOCK, WINDOW, ... ))

La ventaja es que podría aumentar la portabilidad del código SuperBasic de un modo a otro.

No había probado OSUSQ en modo 8, así que hice la prueba. Los paneles aparecen en su sitio, el logo hace el flash del parpadeo horizontal y comentando las líneas que tenían un posicionamiento de caracteres con AT x,y el programa ¡¡funciona!! . Si en todos los sitios hubiera usado CURSOR en lugar de AT y hubiera tenido en cuenta el ancho doble de los caracteres el programa serie compatible en los dos modos. En realidad comentando la línea 8490 de OSUSQ funciona con las opciones por defecto (se puede jugar) con las molestias anteriores.

Si un juego se diseña para modo 8, usando letras con CSIZE 2,0 o superior y usando posiciones absolutas en pixels (con CURSOR, en lugar de AT), el programa sería perfectamente portable entre modo 8 y 4 (sin cambiar a penas nada, sólo se perderían los 8 colores que pasarían a 4).

Supongo que esta "portabiliad" entre modos es la razón de diseño de este comportamiento de SuperBasic que estamos comentando, tal vez no sea un fallo sino que pensaron en esta supuesta "portabilidad".

Voy a intentar ahora poner en pantalla en multitarea dos programas que tengan distinto "modo" (uno en modo 4 y otro en modo a ver qué pasa (no se si se podrá hacer), ya les cuento.

[badaman]

Me he topado con una rutina de C/M para SuperBASIC, que creo era de Zerover, de los tiempos en que programabamos algo...

Esta rutina se encarga de volcar una zona de memoria a otra zona de memoria.

Su utilidad en el juego puede ser importante, ya que, una vez tengamos diseñado todo el fondo de pantalla del juego, podemos cargarlo en memoria y volcar el diseño a la memoria de pantalla tantas veces sea necesario, por ejemplo al iniciar una partida, etc...

Con esto la pantalla se dibujará en un tris-tras.

Vamos con el código:

Código: Seleccionar todo

100 REMark volcado de memoria
110 REMark 1988
120 disp$="flp1_"
130 MODE 8
140 d=RESPR(14)
150 c=RESPR(32*1024)
160 POKE_W d+0,8769
170 POKE_W d+2,9795
180 POKE_W d+4,9945
190 POKE_W d+6,46018
200 POKE_W d+8,26362
210 POKE_W d+10,28672
220 POKE_W d+12,20085
230 LBYTES disp$ & "fondo",c
240 CALL d,c,c+32*1024,131072

En la linea 140 reservamos 14 bytes para la rutina volcadora cuya dirección guardamos en "d".

En la 150 reservamos espacio suficiente como para que quepa la imagen "fondo" entera y la dirección la guardamos en "c".

Obviamente, con el TK2 cargado, será mejor usar ALCHP y RECHP en vez de RESPR.

En la linea 230 cargamos el "fondo" en la memoria que habiamos reservado.

Con la linea 240 llamamos a la rutina que vuelca la imagen "fondo":

d: indica la dirección de la rutina
c: la dirección de inicio de la imagen almacenada en memoria.
c+32*1024: la dirección de memoria final del bloque de memoria que vamos a copiar.
y 131072: la dirección de comienzo de la memoria de video donde se volcará la imagen.

Así pues, el programa carga la imagen "fondo" en memoria y la vuelca en pantalla a gran velocidad.

Será interesante ver el código ensamblador.

[badaman]

Aqui mi aportación para usar la rutina anterior.



Puede descargarse la imagen en versión QL desde aquí

[afx]

¡¡Todo como la seda !! ... la rutina en C/M y la imagen de Badaman. El refresco de la imagen en pantalla es rapidísimo. Uno paso más para ir completando el programa. (Además, esa rutina en C/M nos dará muchísimas posibilidades para otros desarrollos).

Buena idea la de la barra amarilla y negra (oportuna por el motivo del juego). Estoy ahora con la integración de esas dos piezas con la maqueta del programa (ya tengo el tema de los niveles, puntos, ... en cuanto lo tenga más presentable lo envío).

Ahora nos queda esperar por los ansiados sprites. Una posible alternativa, si se demoran los mencionados sprites, podría ser la siguiente (a ver si no me enrollo):
- Dibujar el fondo de la zona de juego, en lugar del "ladrillado" cruzado, una especie de "ladrillado" horizontal de 12 pixels de alto, separado en otro archivo y de sólo una fila de ladrillos para que se pueda cargar n filas. Lo bola, cuando llegue a la zona del muro, iría pintando pequeños ladrillos en negro sobre esas zonas para simular el efecto de rompemuros.