Páginas

13 septiembre 2017

piroPAINT 9918 v1.22 review

Nos encontramos ante un editor gráfico cruzado, principalmente pensado para trabajar con el modo gráfico del TMS9918 y formatos de MSX. Contiene esa magia que distingue los desarrollos japoneses, por esta razón me he propuesto hacer este review para que conozcamos mejor las posibilidades de este soft.

En el momento que escribo este texto, la última versión estable es la 1.22 que salio en el 2016. El autor firma con el sello Piroyan soft (@piroyan) y ha continuado su desarrollo corrigiendo y mejorando, desde que publico la primera versión (creo que por el 2011). Actualmente esta trabajando en una nueva versión, de la cual podemos hacernos una idea mediante la demo funcional v2.0 que esta disponible para descargar en su WEB.

Esta aplicación se compone de un solo ejecutable, listo para funcionar en entorno Windows y sus literales se encuentran en Ingles. Al ejecutarlo se muestran dos ventanas: la principal con los menús desplegables más la imagen a editar y una segunda con la caja de herramientas y la paleta.

Ventana principal, ventana de herramientas y herramienta Pixel Converter.

Empieza con una pantalla en blanco de 256x192, aunque desde el menú de edición podemos crear un proyecto nuevo con la resolución que queramos o cargar imágenes BMP y PNG de cualquier tamaño. También se puede cargar imágenes arrastrando directamente el fichero a la ventana principal.

Nota:
El editor puede trabajar en cuadro modos: 99x8, PC-6x01 (2:1), PC-6x01 (1:1) y PC-8801. Al cargar una imagen intenta reconocer el modo activándose automáticamente. Podemos identificarlo fácilmente observando la paleta y si no es la del 9918 podremos cambiar a nuestro modo desde el menú Edit>Edit Mode.

A la hora de dibujar lo hará con las limitaciones del modo gráfico que tengamos seleccionado, que en nuestro caso será el modo gráfico 2 del TMS9918 (screen 2). Se puede dibujar con varios tipos de pincel y diferentes tipos de tramados, utilizando una de las 6 variaciones de la paleta del TMS9918. Dispone de un selector de magnitud, que permite visualizar la pantalla en 6 escalas diferentes (1x a 32x), necesario para poder trabajar cómodamente con nuestra imagen, sin perder detalle.

Otras funcionalidades de edición que dispone, tenemos la de selección de color (cuenta gotas), que captura el color de un punto de nuestra imagen, pulsando sobre él con el botón derecho, y la de pintar tiles, pulsando la tecla CTRL + el botón derecho para capturar el bloque donde este situado el cursor y CTRL + el botón izquierdo para pintar el bloque. Si nos equivocamos, disponemos de un undo/redo múltiple.

Una vez que tengamos finalizada nuestra imagen, podemos guardarla en formato bitmap o si tiene la resolución adecuada (256x192), podremos exportarla a: binario, formato .CAS o fichero de audio WAV para poder cargar directamente desde el puerto de casete de un MSX.  En el caso de exportar a binario, este generará tres ficheros con las tablas separadas de: patrones, colores y mapa, con la opción de incluir la cabecera del formato MSX BASIC. También dispone de la opción Compress, para generar un único tileset, siempre que al procesar la imagen para buscar los bloques repetidos no supere la cantidad de 256.

Contiene una herramienta de conversión que encontraremos en el menú Tool con el nombre de Pixel Converter. Permite adaptar la imagen cargada a diferentes modos gráficos de diferentes VDPs (TMS9918, V9938, V9958, PC-6x01 y PC-8801). Dentro de cada modo gráfico podremos ajustar la conversión con diferentes parámetros como el color, brillo, contraste, etc.. El resultado final, lo podemos guardar a bitmap (BMP o PNG) o si es un modo gráfico de MSX con su resolución adecuada, podremos exportar a binario de MSX BASIC. Solo permitirá trasladar el resultado al editor, si convertimos a modos del TMS9918.


Demo v2
He probado la demo de la versión 2 e incluye mejoras muy notables en la edición. Ya no esta centrado en el TMS9918, permitiendo trabajar en los modos del V9938 (normales y entrelazados), PC-6001, PC-8801mkIISR y del PC-9801VM.

El toolbox ahora incorpora nuevas herramientas para dibujar lineas, rectángulos, rectángulos rellenos y rellenado de superficies. Además dispone de tres tipos de rellenado: Normal, Degradado Vertical y Degradado Horizontal. Otra de las novedades es la posibilidad de editar la paleta, necesario para cuando se trabaja con modos del V9938.

En esta demo no están visibles las herramientas de exportación y conversión. También esta inhabilitado el Grid y la carga/guardado a formato PNG, aunque ha añadido nuevos formatos como el TIFF, ICO, EMF y WMF. Desconozco el motivo, aunque podría ser que el autor esté adaptando estas funcionalidades a los cambios de la versión, por lo que habrá que esperar a la versión final para saber todo lo que incorpora.


Opinión
La versión 1.22 como editor puede resultar un poco limitado ya que no dispone de las herramientas típicas de un programa tipo Paint (líneas, círculos, cuadrados, relleno, etc…), pero compensa con los tramados y pinceles adaptados a las características del screen 2.

Me ha resultado curioso el Grid, que solo se muestra donde está situado el cursor, lo que impide tener una visión de conjunto que encuentro útil para la creación de imágenes para el TMS9918. No quiero decir por ello que sea una mala idea. Me parece muy interesante y es bueno probar nuevas formas de trabajar, aunque no estaría nada mal que en una futura versión integrará una rejilla completa para toda la imagen.

Otra curiosidad es que dispone de una opción de profundidad de color que parece carente de utilidad. Puede resultar confuso tener una imagen de 24 bits sobre la que dibujemos en modo screen 2. Si no es nuestra intención trabajar de esta forma, deberemos pasar por el conversor antes de ponernos a pixelar.

Para mi, la parte fuerte de esta aplicación son las herramientas de exportación y conversión. La conversión, igual que el editor, no es restrictiva y permite tratar imágenes de cualquier resolución, por lo que resulta útil para composiciones artísticas.

La demo de la versión 2 se muestra muy interesante, por lo que esperaré paciente a que Piroyan soft publique la versión final, para hacer un análisis de sus posibilidades.


Contacto:

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.