Goon Docks avança a un bon ritme i van sortint necessitats per a nMSXtiles que vaig afegint sobre la marxa, menys el tema de Polka! (explicat més endavant), que ha estat una proposta de SapphiReque m’ha semblant prou interesant i fàcil d’afegir en facilitarme l’estructura dels fitxers Polka!.

Les funcionalitats noves per aquesta versión son:

• Desplaçar píxels cap a la dreta, esquerra, a dalt i a baix, a la zona de definció d’un tile.
• Flip horitzontal i vertical de la zona de definició d’un tile.
• Exportar la pantalla i els bancs de definició de tiles en format binari comprimit amb Pletter v0.5b.
• Afegida opció “Load from library” per poder carregar un fitxer de definició de tiles de nMSXtiles a qualsevol dels bancs actuals. Així per exemple, es pot tenir un fitxer amb lletres o números utilitzats a vàries pantalles i anar carregant-los a cada una de elles. O una librería d’elements gràfics com poden ser arbres, pedres, etc. També, metre no programo un botó a tal efecte, seria un mètode per copiar un banc sencer a un altre.
• Importar i Exportar projectes de Polka! v1.2.

Per a suggeriments “urgents” programables en un temps raonable, raó aquí baix…

En Google Code, a la secció de descàrregues, hi ha l’executable per a Windows i el codi font, compilable per Linux, Mac i Windows.

Nota: Publicada versió 0.6.1 on s’ha corregit el bug que feia petar el programa en fer click amb el butó dret del ratolí a la part inferior de la pantalla d’assignació de tiles.

Mentre el grafista termina algunes pantalles més del Goon Docks, he afegit algunes modificacions a nMSXtiles, algunes de les quals ja hi eren a la versió que fem servir a  8bgames:

• Es dibuixa un cursor a la possició d’aquest a la zona de pantalla.
• En sel·leccionar una àrea de la zona de pantalla es va dibuixant el rectangle de sel·lecció.
• S’han assignat extensions per defecte als fitxers d’nMSXtiles, encara que es pot continuar treballant amb extensions pròpies.
• En obrir i guardar fitxers es recorda el darrer directori obert com a directori de treball.
• La pantalla i la definició de tiles es pot exportar en format binari com una seqüència de valors de 8 bits. D’aquesta manera és fàcil afegir-lo directament en codi ensamblador o passar-lo a alguna aplicació de compressió de dades, com per exemple pletter.

A més, recordar que és possible sel·leccionar àrees de pantalla, i amb les tecles Control C i Control V copiar i enganxar. També es poden copiar i enganxar tiles entre bancs de memòria, així com desfer la darrera operación realitzada amb les tecles Control Z.

En Google Code, a la secció de descàrregues, hi ha l’executable per a Windows i el codi font, compilable per Linux, Mac i 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