Goon Docks va avanzado a buen ritmo y nos van surgiendo necesidades en nMSXtiles que voy añadiendo sobre la marcha, a excepción del tema de Polka! (explicado a continuación), que ha sido una propuesta de SapphiRe que me ha parecido interesante y fácil de añadir al facilitarme la estructura de los ficheros Polka!.

Las funcionalidades nuevas para esta versión son:

• Desplazar píxels hacia la derecha, izquierda, arriba y abajo, de la zona de definición de un tile.
• Flip horizontal y vertical de la zona de definición de un tile.
• Exportar la pantalla y los bancos de definición de tiles en formato binario comprimido con Pletter v0.5b.
• Añadida opción “Load from library” para poder cargar una sección de un fichero de definición de tiles de nMSXtiles en cualquiera de los bancos actuales. Así por ejemplo, se puede tener un fichero con letras  o números utilizados en varias pantallas e ir cargándolas en cada una. O una librería de elementos gráficos como puedan ser árboles, piedras, etc. También, mientras no programo un botón al efecto, sería un método para copiar un banco entero en otro.
• Importar y Exportar proyectos de Polka! v1.2.

Para sugerencias “urgentes” programables en un tiempo razonable, razón aquí abajo…

En Google Code, en la sección de descargas, está el ejecutable para Windows y el código fuente, compilable para Linux, Mac y Windows.

Nota: Publicada versión 0.6.1 donde está corregido el bug que hacía petar el programa al hacer click con el botón derecho del ratón en la zona inferior de la pantalla de asignación de tiles.

Mientras el grafista acaba de terminar algunas pantallas más del Goon Docks, he añadido algunas modificaciones a nMSXtiles, algunas de las cuales ya estaban en la versión que utilizamos en 8bgames:

• Se dibuja un cursor en la posición de éste en la zona de pantalla.
• Al seleccionar un área de la zona pantalla se va dibujando el rectángulo de selección.
• Se han asignado extensiones por defecto a los ficheros de nMSXtiles, aunque se puede seguir trabajando con extensiones propias.
• Al abrir y guardar ficheros, se recuerda el último directorio abierto como directorio de trabajo.
• La pantalla y la definición de tiles se puede exportar en formato binario como una secuencia de valores de 8 bits. De esta manera es fácil incluirlo directamente en código ensamblador o pasarlo a alguna aplicación de compresión de datos, como por ejemplo pletter.

Así mismo recordar que es posible seleccionar áreas de pantalla, y con las teclas Control C y Control V copiar y pegar. También se pueden copiar y pegar tiles entre bancos de memoria, así como deshacer la última operación realizada con las teclas Control Z.

En Google Code, en la sección de descargas, está el ejecutable para Windows y el código fuente, compilable para Linux, Mac y Windows.

Se espera un archivo de 16 píxels de ancho con los sprites (multicolor) en columna. Cada frame deberá estar separado por al menos una línea de píxels transparente. Para cada frame, creará un sprite por cada color que encuentre, excepto el negro. También permite que el frame tenga más de 16 píxels de alto, en cuyo caso indicará el desplazamiento (offset) vertical de cada sprite respecto al frame. Como resultado genera un fichero de texto con los datos de cada uno que se pueden copiar fácilmente a nuestro código.

En Google code está hospedado el mini proyecto nMSXsprites con un ejecutable para Windows y el código fuente que debería compilar en Linux, Windows y Mac con las librerías Qt instaladas.

Aprovechando que vuelvo a trastear con el MSX y que x_mangel también le está metiendo mano, he añadido algunas funcionalidades que nos eran bastante necesarias y que agilizarán el uso de la aplicación:

• Deshacer: CTRL + Z. Esta versión permite deshacer la opción “To Bank” y el asignar un Tile a la pantalla.
• Copiar y pegar un bloque de tiles de pantalla. Por ejemplo, un árbol ya colocado en pantalla, formado por 4 tiles, será posible seleccionarlo y mediante CTRL+C y CTRL+V copiarlo en otras posiciones de la pantalla.
• Con el botón derecho del ratón se asigna el primer tile del banco a esa posición. Es decir, se pone un cero, “se borra”.
• Pasando por encima de la pantalla muestra en la casilla de la parte derecha el número del tile asignado.
• Al guardar un proyecto, si los ficheros de tiles y de pantalla están en el mismo directorio que el del proyecto, no guarda el path absoluto, facilitando el pasarlo de un equipo a otro.

Son pequeñas funcionalidades añadidas en un par de ratos y poco testeadas. El tiempo que puedo dedicarle ahora al MSX prefiero que sea programando en ensamblador Aunque por supuesto que los bugs que encuentre o me comentéis los corregiré lo antes posible y subiré las actualizaciones pertinentes.

Proyecto de ejemplo: En el enlace example.zip está comprimido el proyecto del pantallazo que encabeza este post. Con nMSXtiles se debe abrir el fichero nemesis2.prj. Está realizado en 1 minuto con la utilidad para importar gráficos de nMSXtiles (bueno, en jugar al Nemesis 2 para llegar ahí y capturar la pantalla quizás tardé 2 minutos; que sin joystick cuesta más )

En Google Code, en la sección de descargas, está el ejecutable para Windows y el código fuente.

Las clasificaciones dependen de lo que se quiera clasificar. Dicha esta perogrullada, una posible clasificación de los proyectos informáticos serían los que dependen únicamente de los informáticos y el cliente final, y por otro lado, los que dependen de los informáticos, profesionales de otras disciplinas y el cliente final.

En esta última clase, surgen problemas que hay que tener en cuenta, inexistentes si únicamente hay que tratar con el cliente final. Ejemplos del primer caso serían una web o un programa de gestión, en que como mucho, externamente se puede depender del ISP, pero que suelen ” hablar el mismo idioma”. Un ejemplo del segundo sería una automatización ( de un riego de cultivos, una planta, etc ). Aquí, a parte, pueden entrar en juego maquinistas, instaladores de componentes mecánicos, electricistas o electrónicos. El problema es que los informáticos piensan como informáticos, los electrónicos com tal, los electricistas, operarios, o montadores a su manera, etc. En términos informáticos, la API de intercamio de información entre estos gremios no está bien definida y puede llegar a requerir más atención nuestra de la estimada inicialmente. Y normalmente, la parte informática es la última en implementarse, con el consiguiente peligro de tener que absorber los posibles cambios o descoordinaciones en los pasos anteriores.

¿Cómo plantearse estos proyectos? Pues no tengo una lista de 10 reglas, ya que mi experiencia no es tan dilatada, pero según los casos que me he encontrado, dependerá básicamente de lo que se vaya a automatizar y de quién lleve el peso del proyecto. Por lo que he visto, contra más tierra haya, más problemas podemos tener. Es decir, si es por ejemplo una planta, seguramente el responsable de sistemas tenga claro lo que quiere y trabajará conjuntamente con los electrónicos para que controlen los procesos y con los informáticos para que recojan todos esos datos y los exploten (Scada). Pero si en el proyecto hay tierra, hay obras; y si hay obras, lógicamente el peso del proyecto lo lleven ingenieros de caminos, con jefes de obra, encargados y tal que, por lo que yo he visto, el tema de la automatización lo tienen más flojo, o al menos, están menos sensibilizados a la hora de por ejemplo, vigilar no cargarse un bus de comunicaciones con una máquina por hacer un agujero precipitadamente.

En estos proyectos, seguramente desde que se comienza la obra hasta que lleguemos nosotros a instalar el software pasen varios meses, con los consiguientes cambios que hayan podido haber durante el transcurso de ésta, algunos de los cuales podrían afectarnos directamente. Lo bueno sería identificar en nuestra aplicación cuáles son los elementos críticos que si sufriesen alguna modificación podrían tener un impacto grande sobre ella, y estar atentos durante el desarrollo de la obra por si se modificasen. Por ejemplo, en una automatización de riego de varios kilómetros, quizás hemos contado con montar 3 buses de comunicaciones y 3 puestos de control. Para ello nos han asegurado enganches eléctricos en ciertas zonas. Podría darse el caso de que uno de estos enganches se retrase mucho o que simplemente nos diga luego la compañía que ahí no puede ir: ¿nuestra aplicación es capaz de soportar un cambio de situación de los puestos de control? O hay que hacer un nuevo bus provisional porque antes de la puesta en marcha no se podrán unir dos tramos: ¿nuestra aplicación soporta el añadido de un nuevo bus? A ver, soportar lo debería soportar, pero ¿lo podemos reconfigurar fácilmente?Debemos actualizar un sistema viejo con comunicaciones por radio a uno con comunicaciones por cable. A última hora, por retrasos en las obras, vemos que no dará tiempo a actualizarlo todo antes de la puesta en marcha: ¿soporta nuestro sistema funcionar en modo mixto?

Otro punto es el intercamio de información entre la parte electrónica (autómatas, sensores, actuadores) y nosotros. Aunque informáticos y electrónicos son más afines, no hay que confiarse. Por ejemplo, en el control de algún proceso, si no lo hemos tenido que diseñar nosotros, únicamente nos deberán pasar las variables necesarias para actuar sobre él; fácil. El problema puede venir si nosotros tenemos que diseñar el algoritmo de control y no somos quienes programamos los autómatas. Se piensa un algoritmo y se le pasa a los programadores de autómatas. Pero éstos, al menos con los que yo he trabajado, suelen usar Grafcets para programarlos. De momento nunca hemos conseguido que el algoritmo haga lo que se pensó al 100%. ¿Qué suele suceder entonces? Que es la parte final, se va contrareloj, se testea y si el control funciona en líneas generales, ya está. Entonces, aún quedando pequeños detalles que en según qué circunstancias el control acaba haciendo “algo parecido” a lo pensado inicialmente, resulta difícil justificar un retraso en la entrega porque el algoritmo no actúe exactamente como se pensó, si está cumpliendo en un 95% su funcionalidad.

Como resumen, en proyectos de este tipo, mejor tener muy bien identificados los puntos críticos de nuestra aplicación y estar muy atentos a posibles cambios que les puedan afectar.

He añadido una funcionalidad para poder importar a los bancos de tiles una imagen en formato PNG creada con nuestro editor gráfico favorito. De esta manera tendríamos estos tiles disponibles para crear las pantallas. Según la documentación, QImage puede leer además archivos en formatos: GIF, JPG, PBM, PGM, PPM, TIFF, XBM y XPM, aunque hay que hacer unas comprobaciones que no he hecho (si alguien quiere probar).

El programa espera un fichero de 256 x 192 píxels respetando las restricciones de color del MSX y asignará cada tercio a cada uno de los tres bancos de tiles.

Como no tenía ningún ejemplo mio, he capturado una pantalla de un “conocido juego” como si la hubiese diseñado por ejemplo con el GIMP. Aunque la utilidad real sería para otro tipo de pantallas que aprovechen el concepto de tile, no me he podido resistir a ver cómo quedaba la nave.

El “pequeño” problema lo tenemos a la hora de trabajar con las paletas. He buscado una solución fácil para mi y a la vez creo que flexible. En vez de trabajar con ficheros que llevan la paleta o intentar determinarla, el programa espera a parte, un fichero Paleta en el que los primeros 16 píxels de la primera fila tendrán los colores utilizados. Es decir, los píxels 0 y 1 espera que estén con el tono de negro que hemos utilizado en el dibujo de tiles, igual para los verdes de los píxels 2 y 3, etc.

Aquí dejo el ejecutable para Windows y el código fuente:

Archivos:

Fuentes v0.2.5

Ejecutable v0.2.5 – Windows

En un proyecto se pueden diseñar hasta cuatro conjuntos de cuatro planos de sprites cada uno. Faltarían añadir algunas utilidades como copia de sprites y desplazamiento de bits, pero será para una futura versión.

Como siempre, comentarios y sugerencias varias serán bienvenidos.

Archivos:

Fuentes v0.2.4

Ejecutable v0.2.4 – Windows

En unos ratos libres que he tenido he programado un editor de pantallas y tiles para el screen 2 del MSX.

Es la versión 0.2, o sea que está bastante verde, pero ya es funcional. El programa está pensado para crear los fondos estáticos de las pantallas de juegos en 2D. El juego Zambeze que hice sería un claro ejemplo de uso.

La filosofía del programa es abrir un proyecto que constará de una pantalla y tres bancos de tiles (parte superior, media e inferior de la pantalla). Tiene un editor de tiles de 8×8 píxels (con las restricciones de color del screen 2) que se podrán asignar a los bancos de patrones y después posicionar sobre la pantalla. Existe la opción de exportar la pantalla y los bancos de patrones y colores a datos en pseudocódigo para ASM. Como el que uso es el asMSX he utilizado esa notación, pero se podría modificar para otros ensambladores.

Está claramente inspirado en el ICVGM que es el que estaba utilizando hasta ahora y que va bastante bien, pero tenía ganas de hacer algo parecido.
El programa está probado para Windows y Linux, pero si tenéis curiosidad, está disponible el código fuente para poder modificarlo y compilarlo.

Hombre, lo bueno sería que si alguien se decide a modificarlo notablemente, se abra un hilo de desarrollo y vayamos añadiendo funcionalidades y tal, pero vamos, cada uno es libre de hacer lo que quiera con el código.

El programa está hecho en C++ utilizando las librerías multiplataforma Qt4 de Trolltech. Para Windows he usado el compilador MinGW, que la misma instalación de las Qt ya da la opción de bajarlo e instalarlo (a veces falla el intento de bajarlo a la primera; hay que reintentarlo un par de veces).

Archivos:

Fuentes v0.2

Ejecutable v0.2 – Windows