Páginas

01 agosto 2017

Sprites MSX · La regla del quinto Sprite

Una de las limitaciones que tendremos que tener en cuenta a la hora de diseñar una aplicación con el TMS9918, es la regla del quinto sprite. Esta consiste en que solo se pueden mostrar 4 sprites horizontalmente. Si se sitúa un quinto o más sprites en la misma franja horizontal, no se visualizarán. Qué sprites se muestran y cuáles no, dependerá del número de plano en el que se encuentren, ya que tienen preferencia los planos superiores.

Hay que tener en cuenta de que el VDP dibuja la pantalla línea a línea por lo que esta limitación actúa a nivel de línea, es decir, solo aquellas partes de los sprites que se encuentren afectadas por esta limitación no se dibujarán, por lo que dependiendo de la posición de estos se podrá ver sprites parcialmente dibujados.


Notas:
Esta norma tiene en cuenta todo el área del sprite (8x8 o 16x16), independientemente de si el patrón tiene puntos dibujados o se muestran con el color 0 (transparente).

Los video procesadores que contengan compatibilidad con el TMS9918, dispondrán de la misma limitación en los modos iguales (el V9938, el V9958 o el VDP de la Sega Master System).

En los nuevos modos gráficos de los vídeo procesadores V9938 y el V9958, dispone de la misma limitación pero con la mejora de que se ha duplicado su capacidad, permitiendo hasta 8 sprites por línea. En el V9990 se podrá mostrar hasta 16 sprites horizontales.


Ejemplo 1


A continuación tenéis un ejemplo en MSX Basic donde podéis probar cómo afecta la ley del quinto sprite a dos visualizaciones diferentes: horizontal (desaparece la totalidad del quinto sprite), o en escalera (afecta a una parte del quinto sprite).
10 REM Ejemplo Regla del Quinto Sprite
20 SCREEN 1,2:KEY OFF
30 WIDTH 32
40 PAT=BASE(9):REM tabla de patrones de sprite
50 Y=80
60 FOR BC=PAT TO PAT+31:VPOKE BC,255:NEXT
70 PRINT "[UP] o [DOWN] mueve sprite 4"
80 PRINT "F1 Salir"
90 PRINT "F2 Horizontal"
100 PRINT "F3 Escalera"
110 ON KEY GOSUB 400,200,300
120 KEY(1) ON:KEY(2) ON:KEY(3) ON
130 GOSUB 200
140 PUT SPRITE 4,(120,Y),13,0
150 IF STICK(0)=1 THEN Y=Y-1
160 IF STICK(0)=5 THEN Y=Y+1
170 GOTO 140
200 PUT SPRITE 0,(40,100),1,0
210 PUT SPRITE 1,(60,100),3,0
220 PUT SPRITE 2,(80,100),6,0
230 PUT SPRITE 3,(100,100),7,0
240 RETURN
300 PUT SPRITE 0,(40,100),1,0
310 PUT SPRITE 1,(60,104),3,0
320 PUT SPRITE 2,(80,108),6,0
330 PUT SPRITE 3,(100,112),7,0
340 RETURN
400 END
Descargar Ejemplo 1: SPRITE5.BAS


Técnica para hacer desaparecer un sprite verticalmente con un gráfico de la pantalla.


Aprovechando el efecto de la limitación de sprites horizontales, podemos utilizarla para que nuestras figuras se oculten en una área determinada de la pantalla, generando el efecto de que están pasando por debajo de un gráfico. Este truco solo funciona con bloques horizontales múltiplos de 8 o 16 líneas, según el tipo de sprites que tengamos configurado en la pantalla.

El efecto es muy sencillo. Añadiremos cuatro sprites con color 0 en la misma coordenada vertical con planos superiores al resto de figuras (por ejemplo los planos del 0 al 3).

Si queremos que este truco no afecte a un grupo de sprites para que estos se muestren por encima del gráfico, tendremos que colocarlos en planos superiores a los utilizados para generar este efecto.

Un caso práctico sería su uso en un marcador horizontal, en la parte superior o inferior de la pantalla.


En la imagen podemos ver en el plano 0 una figura de color verde que se muestra por encima del gráfico de ladrillos. En los planos del 1 al 4, se ha utilizado un patrón de un recuadro mostrado en azul para distinguirlos (a la práctica utilizaremos color 0). El sprite blanco se encuentra en un plano inferior por lo que desaparece la parte que colisiona con los primeros planos realizando el efecto de ocultación por detrás de los ladrillos.


Como utilizar 3 o más colores para un personaje y que afecte como 2 sprites horizontales


A la hora de dibujar una figura se suele utilizar una matriz de 16x16 y se suele pintar con los diferentes colores que necesitemos. A la hora de programar tendremos que usar un plano por color, por lo que nos podemos encontrar muy rápido con la regla del quinto sprite. Hay una forma de economizar el uso de planos horizontalmente que consiste en dibujar nuestros sprites de forma que colocados verticalmente solo se solapen 2 horizontalmente. De esta forma podemos concatenar verticalmente tantos sprites como necesitemos para completar la altura de nuestro personaje.




En las imágenes podemos ver la forma incorrecta y correcta de crear los patrones y colocarlos en la pantalla. Hemos utilizado un sprite para el color principal (amarillo) y dos sprites colocados verticalmente para dar los colores de detalle de la parte superior y la parte inferior de la figura.


Técnica de parpadeo de sprites (sprite flicker)


Para poder mostrar más de 4 sprites horizontalmente, se suele utilizar una técnica mediante software que consiste en cambiar la prioridad de los planos en cada interrupción de barrido de la pantalla (VBLANK). Esto produce un parpadeo en los sprites afectados por la regla del quinto sprite.

Ilustración del funcionamiento de la técnica de Sprite Flicker. En un MSX real la frecuencia es mucho mayor (50 veces por segundo en PAL).

Una rutina de Sprite Flicker se basa en disponer de una copia de la tabla de atributos de Sprite (OAM), en RAM, donde se escribirán los cambios de las figuras móviles de nuestro motor de juego. La rutina de parpadeo generará las modificaciones con la técnica necesaria a un segundo buffer, que es el que se volcará a la VRAM en la interrupción de VBLANK.

Aunque en muchos casos pueda funcionar una rutina genérica, dependiendo del diseño del juego puede ser necesario crear una que afecte de una forma muy concreta a un rango de sprites. Por lo general, se suelen reservar los primeros planos para la figura del personaje principal y dependiendo del caso, la de otros personajes. Se suele dejar para la rutina de Flicker, los planos utilizados con la intención de dar un color de detalle de los personajes y no importe que en un momento dado parpadee. Donde más interesa utilizarla es en sprites que estén en continuo movimiento y se puedan ver afectados en determinados momentos, como por ejemplo en los proyectiles o enemigos de un shooter vertical.

Es aconsejable que a la hora de diseñar un juego, controlar la cantidad de sprites utilizados y cómo se pueden ver afectados por la regla del quinto sprite, ya que un exceso de parpadeo puede ser molesto y hacer que el juego pierda jugabilidad.

La forma de intercambiar los planos podrá resolverse de diferentes formas, dependiendo del caso. Habrá ocasiones donde si tenemos muy controlado como se muestran los sprites, se pueda resolver intercambiando los atributos entre dos bloques, mientras que en otros, puede ser necesario una técnica por rotación o inversión, como la que he utilizado en el Ejemplo 2. Un ejemplo de inversión seria trabajar con los atributos de los planos 10 al 20 e invertirlos para que el 20 pase a ser el 10, el 21 el 11 y así hasta el último.


Ejemplo 2 


El ejemplo descargable está realizado en ensamblador para Sjasm Z80 v0.42c de XL2S Entertainment. En el se puede ver el efecto de ocultación horizontal y del funcionamiento de la técnica de parpadeo de sprites. Incluye una rutina de parpadeo por inversión que he programado y que podéis usar y modificar libremente, para vuestros desarrollos. Se puede ajustar el rango de sprites que han de funcionar dentro de la inversión de planos. Pare ello podéis modificar las valores de las etiquetas: SPRFLK_INIT y SPRFLK_END.


Referencias

13 febrero 2017

Sprites MSX · La OAM

Cuando tengamos definidos una serie de patrones de Sprites, podemos visualizarlos desde el lenguaje Basic con la instrucción PUT SPRITE, pero otra forma que podemos utilizar, sobretodo si trabajamos en Ensamblador o con C, se basa en escribir en una zona concreta de la VRAM llamada Object Attribute Memory (OAM).

En esta tabla se guarda la información de visualización de los planos de Sprites. Utiliza 4 Bytes para cada uno de los 32 planos disponibles, dispuestos en orden consecutivo y podemos definir la siguiente información:
  1. Coordenada Y
  2. Coordenada X
  3. Número de patrón.
  4. Color + EC (bit 7 Early Clock)
En los modos gráficos G1, G2 y MC (screen 1, 2 y 3), del TMS9918, esta se encuentra en la posición 1B00h, mientras que en los modos gráficos del V9938 esta tabla se ubicará en diferentes posiciones de la VRAM (ver Tabla 1).

Modo VRAM
G1,G2 y MC 1B00h
G3 1E00h
G4 y G5 7600h
G6 y G7 FA00h
Tabla 1. Tabla de Atributos de Sprite (OAM).

En los nuevos modos gráficos del V9938, el valor de color no se utiliza, ya que se necesita 16 bytes por plano de Sprite. Para ello se dispone de una extensión de la OAM. Como en los sprites del TMS9918, además de la información de color, también se incluye un bit para el Early Clock, otro para la combinación de colores (OR) y uno más para la colisión de Sprites (ver post: sprites del V9938). Esta tabla se encuentra en diferentes posiciones de la VRAM, dependiendo del modo de pantalla (ver tabla 2).

Modo VRAM
G3 1C00h
G4 y G5 7400h
G6 y G7 F800h
Tabla 2. Tabla de atributos de colores de Sprite.

Un detalle a tener en cuenta, es que cuando trabajemos con Sprites de 16x16, al asignar el número de patrón a un plano, tendremos que multiplicar su valor por 4, ya que es la forma interna de trabajar del VDP. Esto es debido a que se componen de 4 sprites de 8x8.

Si programamos en ensamblador, la BIOS del MSX contiene funciones que nos pueden facilitar algunas tareas. La función CALATR (0087h), nos devolverá en HL la dirección de la VRAM donde se encuentra la información del OAM, del número de plano indicado en A. Además, se ajusta al modo de pantalla que estemos utilizando, independientemente de la generación de MSX que se trate.

En el desarrollo de juegos. la visualización de Sprites se puede trabajar de varias formas: Podemos tocar los Sprites directamente en la VRAM cuando se requiera, como haríamos en Basic con Put Sprite, o se puede crear un buffer en RAM, que volcaremos a la VRAM en la interrupción de VBlank. Esta segunda puede ser la mejor opción si utilizamos muchos Sprites, sobretodo por que el acceso a RAM siempre será más fácil y rápido que a la VRAM.

Desde Basic también puede ser útil acceder directamente a la OAM con VPOKE, para casos que solo tengamos que modificar un parámetro de un plano de Sprite, como por ejemplo si queremos que se desplace horizontalmente solo necesitaríamos tocar el valor para la coordenada X.


Ejemplos 

Acceso a la OAM desde Basic:
10 REM EJEMPLO ACCESO AL OAM
20 SCREEN 1,2:REM screen 1 con sprites de 16x16
30 IX=BASE(8)::REM OAM para screen 1,2 y 3
40 PAT=BASE(9):REM tabla de patrones de sprite
50 FOR BC=PAT TO PAT+(2*32):VPOKE BC,255:NEXT
60 REM PUTSPRITE 0,(100,80),1,0
61 VPOKE IX,80:REM coordenada Y
62 VPOKE IX+1,100:REM coordenada X
63 VPOKE IX+2,0:REM n patron * 4 en sprites de 16
64 VPOKE IX+3,1:REM color negro
70 REM PUTSPRITE 1,(200,110),8,1
71 VPOKE IX+4,110:REM coordenada Y
72 VPOKE IX+5,200:REM coordenada X
73 VPOKE IX+6,(1*4):REM n patron * 4 en sprites de 16
74 VPOKE IX+7,8:REM color rojo
Descargar ejemplo 1: OAME.BAS


Referencias:

15 junio 2016

Sprites MSX · Desaparece por la izquierda (Early Clock)

En un post anterior comenté como ocultar un sprite o grupo de sprites (ocúltate en la 208), pero en esta ocasión vamos a tratar el como hacer desaparecer un sprite por los bordes laterales de la pantalla.

Si mostramos un sprite en la posición 0,0 se situaría en la esquina superior izquierda de la pantalla y si lo movemos hacia la derecha llegaría un momento en el que empezaría a desaparecer por el borde derecho de la pantalla. Esta posición empieza en la coordenada 241 y va hasta la 255, pero en esta última posición no se acaba de ocultar todo el sprite ya que se mostraría la primera linea, por lo que el siguiente paso seria sacarlo de la pantalla, por ejemplo posicionandolo en la coordenada Y = 209.

Pero... ¿como hacemos que desaparezca por el lado izquierdo?

Las figuras móviles (sprites), disponen de un byte para el valor de posicionamiento horizontal, dentro de la tabla de atributos OAM (Object Attribute Memory), por lo que queda limitado a 256 posiciones, las mismas que el ancho de la pantalla. Para poder desplazar 16 pixels más, necesitaríamos un bit más pero nuestro VDP solo dispone de registros de 8bits. Por suerte el TMS9918 ha solucionado el problema utilizando un bit de otro atributo.

Este bit es el llamado Early Clock (EC) lo tenemos dentro del valor de color del sprite. Como para el color solo es necesario de 4 bits el VDP aprovecha uno de los sobrantes para este menester, en concreto el número 7.

¿Que pasa si ponemos a 1 este bit?
Es muy simple. Desplaza 32 pixels a la izquierda la posición que tengamos marcada en la coordenada X. Eso quiere decir, que si tenemos el sprite en la posición 0, al activar el bit de EC desaparecerá completamente de la pantalla ya que se encontrará oculto en la coordenada -32 de la pantalla. Para que nuestra figura desaparezca como es debido tendremos que controlar la coordenada X, por lo que si nuestro sprite queremos situarlo en la posición -1, le tendremos que dar el valor 31.

Una forma de ilustrar como se programaría, en Basic seria de la siguiente manera:
vramaddr = tablaOAM+(planosprite*4)
VPOKE vramaddr+3 , 128+color
VPOKE vramaddr+1 , 24:REM coordenada X=-8
La dirección en la VRAM de la tabla OAM es la misma en screen 1 y 2 y se sitúa en la posición 1B00h.

Ejemplo:
10 SCREEN 1,2
20 FOR i=14336 TO 14367:VPOKE i,255:NEXT
30 PUT SPRITE 0,(0,88),7,0
40 PUT SPRITE 1,(24,104),3,0
50 v=BASE(18):REM direccion tabla OAM
60 VPOKE v+3,128+7:REM activa bit EC + color
70 VPOKE v+1,32-8:REM coordenada X
Nota: Una vez ejecutado este ejemplo puedes probar a cambiar la coordenada X escribiendo con VPOKE en la dirección 6913 (equivale al valor de X para el plano de sprite 0).


En el ejemplo podemos ver como dos sprites colocados en la misma posición horizontal (el del plano 0 le hemos dado el valor 24 en la línea 70), el de colo cían se muestra en la posición -8, gracias a la activación del bit EC (línea 60).

Si programas en MSX Basic la forma del ejemplo anterior no es necesaria ya que utilizando la instrucción Put Sprite, ya lo hace todo por nosotros. Solo tendrás que introducir el valor negativo de desplazamiento para la coordenada X y ya esta!

Ejemplo:
PUT SPRITE 0,(-8,88),7,0

¿Y en el V9938?
Ya que estamos, vamos a ver como ha evolucionado este concepto en el VDP de los MSX2.

Este video procesador ademas de la OAM, contiene una nueva tabla para los colores de los sprites, que ahora permite asignar un color por linea y como en el TMS9918, aprovecha los bits libres para añadir más funcionalidad. El Early clock también se encuentra en el bit 7 y de igual modo generará un desplazamiento de 32 pixels hacia la izquierda, pero en este caso se tendrá que modificar en los valores de todas las lineas. Personalmente no se me ocurre una idea práctica para querer desplazar diferentes partes de un sprite, pero la posibilidad ahí esta para aquellos que lo necesiten.

En screen 5 y 6, la tabla de colores de los sprites se encuentra en la posición 7400h, mientras que en screen 7 la tenemos en F800h.


Referencias:

14 abril 2016

Mapas de la VRAM de modos gráficos del MSX

He creado varios mapas de memoria correspondientes a varios modos de pantalla de configuraciones estándar utilizadas en los MSX

Utilizo colores para identificar los diferentes tipos de datos e indico la dirección en la VRAM y el tamaño de la tabla. 

Tenéis completa libertad sobre ellos. Podéis imprimirlos o publicarlos en vuestros documentos, ya sean impresos o electrónicos. 

Adjunto también los documentos en formato SVG por si los queréis modificar. Para su creación, he utilizado inkscape
  • Modo T1 (screen 0) (PNG) (SVG)
  • Modo G1 (screen 1) (PNG) (SVG)
  • Modo G2 (screen 2) (PNG) (SVG)
  • Modo MC (screen 3) (PNG) (SVG)
  • Modo G3 (screen 4) (PNG) (SVG)


NOTA: Actualizado el 24/2/2017. La tabla para el modo G2/G3 contenía un error: La tabla de la OAM no es la misma en los modos G2 y G3. Se han separado en dos tablas.

08 julio 2015

Proyectos en verano del 2015

Empezó el verano y estamos atravesando una cadena de olas de calor. En mi caso, me deja bastante chafado con ganas de meterme en una cámara de hibernación programada para despertar en septiembre. Como esto ahora mismo no es posible, intentaremos pasarlo lo mejor posible.

Los que seguís mis proyectos, los he tenido parados por mi contribución en las pasadas Commodore Explora y la 47 RU de MSX de la AAMSX, pero sigo con ellos, aunque sea en los ratos en los que la cafeína me produce su mayor efecto. En los otros me podéis encontrar de veraneo virtual en Los Santos como multivac7 (GTAV online) ;P

Tengo pendiente publicar una primera versión del AmiVJing. La Commodore Explora me motivo bastante para ponerme a programar con el Amiga y quise añadir unos cambios pero los resultados no han sido los esperados. Después de pelearme más de una semana con varios problemas, me he quemado un poco y lo he dejado descansar. Seguramente tendré que echar atrás la versión.

En estos momentos estoy resolviendo funcionalidades del tMSgfX. Aunque sea poquito lo que le dedique al día a la larga formará un mucho. Ahora mismo el editor de mapas esta bastante avanzado. Le he añadido una herramienta de selección de un área que realiza un copy y luego permite plasmarlo como una herramienta de dibujo. También hay la opción para crear un nuevo mapa a partir del área copiada. Otra de las funcionalidades acabadas es la de la ventana de salida a código, además de otras funcionalidades internas.



Iré contando mis avances en este blog o en mi cuenta de twitter: @aorante

Saludos y feliz verano!

06 mayo 2015

MSX devtools >> tMSgfX

El año pasado, después de publicar varias versiones de spriteSX y de MSX tiles devtool, empecé una nueva versión de esta última aplicación a la cual añadí bastante funcionalidad. Permitía trabajar (dentro de sus posibilidades), con toda la información que abarca el chip de vídeo del TMS9918, por lo que añadí al control visual que emula este VDP, la visualización de sprites y la representación del modo de texto screen 0 y el modo gráfico 1.

Debería haber publicado una versión, pero me entusiasme añadiendo el editor de sprites (spriteSX), y al final salte directamente a la idea que me rondaba desde hace un año: crear una aplicación completa para la edición gráfica cruzada del TMS9918, a la cual he bautizado como tMSgfX.


Ventana principal de la aplicación


Lo anuncié a principios de este año por twitter y se hizo eco en algunos medios de la escena MSXera, lo cual agradezco, ya que anima a seguir adelante.

Ahora que se encuentra en un estado avanzado de desarrollo, toca anunciarlo en mi blog, el cual tengo bastante abandonado últimamente.

El proyecto ya tiene un editor de tiles y de mapas, bastante avanzados (en otro post entraré en detalles de sus características), a demás del editor de sprites: spriteSX, el cual se ha beneficiado del know how que he adquirido durante este tiempo, con mejoras que se podrán ver en una próxima versión que estará disponible para la 47RU de MSX (mi deadline es el 13 de junio! :P ). Intentaré hacerme un hueco en la zona de desarrolladores de la RU para poder mostrar un prototipo del tMSgfX.


Estado actual del editor de tiles.


Además de lo dicho, quiero añadirle un editor de OAM (Object Atribute Memory), para el posicionamiento de sprites en una pantalla, pensando inicialmente en composiciones gráficas que utilicen sprites. No creo que este para la primera versión del tMSgfX, para no alargarlo mucho en el tiempo.

También informo que el proyecto que estaba bajo el sello de 303bcn, pasa ahora a depender de la asociación gatAtac! Quiero aprovechar la plataforma de gestión de proyectos de esta, para el desarrollo de las MSX devtools y utilizar 303bcn para temas más creativos (VJ, música y demoscene).

Estado actual del editor de Mapas.


Nota: Las imágenes son capturas del estado actual de las aplicaciones. La versión final puede ser muy diferente.

26 agosto 2014

spriteSX devtool v0.9.4b


En estos días de verano, a pensar del aletargamiento por el calor, he sacado algunas horas para hacer algo de provecho y ha salido esta versión del spriteSX con algunas herramientas que creo interesantes para los que dibujéis figuras móviles para el TMS9918 y V9938.

Ahora dispone de herramientas tipo Paint, para hacer líneas, rectángulos, circunferencias y rellenado. Todas pueden actuar en positivo o negativo según el botón del ratón que pulsemos y los rectángulos y circunferencias pueden ser con o sin relleno. En una versión próxima quiero sustituir la herramienta de circunferencia por elipses.

Quizás estas herramientas no sean muy interesantes, sobretodo en el caso de una figura de solo 8x8, pero nadie me negará que la siguiente funcionalidad es de lo más útil. Para que podáis echar atrás algún paso que no os guste como os ha quedado, le he añadido un Undo/Redo de 16 pasos.

Otra funcionalidad que he añadido, son atajos de teclado, para los que prefiráis esta forma de acceder a las funcionalidades de la aplicación.

También he corregido un par de bugs y le he añadido ejemplos en ensamblador.

Aprovecho para agradecer la ayuda de Fubu y JamQue, que en una merienda de colas y sandwiches de nocilla, me echaron una mano en el desarrollo de dos de las herramientas de esta versión. :)

  • Podéis descargarlo en la WEB del proyecto spriteSX devtool.
  • Tenéis más información de la versión en el Readme.