Karoshi MSX Community

Buenas!

No sé si muchos seguís usando estas herramientas de línea de comandos o tirais directamente de herramientas gráficas... A los de línea de comandos puede que os interese lo que os voy a contar.

Aprovechando que tenía código para leer un PCX (de la primera versión de PCX2SPR) me decidí a hacer una implementación nueva del PCX2MSX de Robsy. En principio no parece muy útil hacer una herramienta que ya existe, pero tiene sus ventajas.
Os digo características / diferencias respecto al anterior / ventajas:

• código fuente disponible: se puede compilar en Linux sin pasar por Wine o similares. Yo no uso Linux, pero alguien me comentó que tenía ese problema y de ahí surgió esto.
• control de la generación de patrones: el PCX2MSX original metía 0xff en las líneas con un único color, lo que provocaba que hubiera que tocar la salida a mano si querías colorear programáticamente (por ejemplo, FILVRM). Ahora se puede controlar (de forma muy básica de momento) cómo se generan esos patrones para automatizar todo lo posible.
• más de información de las colisiones, posibilidad de ignorarlas
• código de retorno correcto: ahora se puede usar en un makefile, en una cadena de comandos, etc. Parece una chorrada, pero yo lo necesitaba. También pensando en makefiles, para tenera una salida más limpia, si todo va bien la ejecución es "silenciosa" por defecto.

Poco más os cuento. Probadlo :) En la mayoría de los casos la transición de un PCX2MSX al otro debería ser transparente.
El cambio más gordo es que PCX2MSXi no existe en esta versión; en su lugar hay un parámetro "-ps" para indicar que el .pcx viene de Photoshop y que lea correctamente la paleta. Que si lo echáis mucho de menos con un .bat está solucionado ;D
También se inlcuye en el paquete PCX2SPR, que como decía antes ahora comparte con PCX2MSX gran parte del código y no tiene sentido publicarlos separados.

Se aceptan sugerencias, comentarios, "este pcx no me lo lee", "necesito que detecte forma/fondo así o asao", etc.
En el futuro quería añadir eliminación de tiles vacíos, tiles repetidos, generar NAMTBL, etc. Si alguien tiene alguna necesidad concreta, pues se puede priorizar.

Espero que os sea útil!
Un saludo!

Enlace de descarga:
Ir al post con la última versión (v0.99)
Ir al post con la última versión (v1.99)
Ir al post con la última versión (v1.99c) (http://karoshi.auic.es/index.php/topic,2472.msg30549.html#msg30549)

Hola,

Pues efectivamente, a los que usamos Linux nos soluciona mucho la papeleta porque así no tenemos que depender de wine ni de rebootar a Windows para transformar una simple imagen.

Gracias a tu trabajo, ahora con la combinación de gimp+asmsx+pcx2msx+pletter (o bitbuster) y con el nMSXtiles de petacour ya se puede hacer un proyecto *integramente* fuera de Windows, solo faltaba esta herramienta que has desarrollado.

MIL gracias, Nestor!!

Un saludote

Ya sabes que yo soy usuario fiel de PCX2MSX! ;). Luego les doy una buena probada, gracias por todo!!

Nestruo: muchas gracias por desarrollar una aplicación así y por bautizarla con el mismo nombre que la original. Por mi parte, al perder el código fuente decidí darla por enterrada, y me alegra saber que ahora tiene su continuidad, aunque tu programa sea mucho más potente y versátil.

Enhorabuena por tu aportación.

Gracias por las respuestas!

@alucardX: yo no soy linuxero así que ya sabes... todas las mejoras que haga te va a tocar betatestearlas :-P

@Jon_Cortazar: ya me contarás qué tal te va! En especial las opciones para facilitar el trabajo con fuentes. Si te animas a empezar a usar PCX para los sprites ya hablaré contigo para que PCX2SPR soporte sprites compuestos con múltiples coordenadas Y

@pitpan: muchas gracias a ti! :D

Buenas noches.
Os traigo una nueva versión de estas dos herramientas, con las siguientes novedades:

• PCX2MSX y PCX2SPR: se elimina el parámetro para leer ficheros de Photoshop... porque ahora lo detecta automáticamente.
• PCX2MSX: ahora es capaz de generar la tabla de nombres, eliminando tiles vacíos y/o tiles duplicados. De hecho, también se puede generar la tabla de nombres sin eliminar ningún tile, pero no tiene mucho sentido.

Está recién salido del horno y no he probado casos extremos (que se eliminen todos los tiles, que haya más de 256 tiles, cosas así). Avisados estáis ;D

El enlace de descarga (v0.99): https://docs.google.com/file/d/0B-dULQ_O2vS4Qzh2dXhfZ3BmNUU/edit?usp=sharing

Buenas tardes.

Tengo lista una nueva versión de PCX2SPR (llamada PCX2SPR+) que es capaz de extraer sprites de un spritesheet.

Esto no parece gran cosa (ya lo hacía PCX2SPR), pero la novedad es que es capaz de hacerlo con sprites multicolor optimizando los sprites por scanline y generando la pertinente SPRATR.
También acepta sprites más grandes (en mis pruebas he utilizado un spritesheet con sprites de 24x32). Explicado de forma visual:
(https://drive.google.com/uc?export=download&id=0B-dULQ_O2vS4SndxTWFFbmlnemc)
(ese sprite en concreto tiene algún pixel que lo hace bastante puñetero ::qbiqsray::)

Por poner un ejemplo, extraería correctamente los del último Malaika :malaika:, que la protagonista tiene 3 colores, 4 sprites (y cada uno en unas coordenadas diferentes) a partir de un PCX con los sprites "compuestos" tal cual se ven en el juego.

Probadlo si quereis y contadme qué tal os va. Se incluye un pequeño asm que presentaría por pantalla los sprites (para verificar que ha hecho bien la extración).

El enlace de descarga (v1.99):https://drive.google.com/file/d/0B-dULQ_O2vS4Wi1SeUxIVzJBQjg/edit?usp=sharing (https://drive.google.com/file/d/0B-dULQ_O2vS4Wi1SeUxIVzJBQjg/edit?usp=sharing)

Que pasada!  :D

estoy haciendo algo parecido para añadirlo al spriteSX, reutilizando una rutina que he programado para convertir imágenes PNG o GIF a SC2, pero solo detecta un color sobre negro o las lineas de color para sprites de msx2, y tiene la limitación que ha de ser una imagen de 256x192 de donde recoge del banco superior 64 sprites de 16x16 o 256 de 8x8.   

Esta bastante evolucionado, pero tengo que añadir un par de funcionalidades. Espero tenerlo para la semana que viene.

con todas estas tools a ver si se anima más gente a hacer soft para MSX!  ;)

Saludos!

(http://lh6.googleusercontent.com/-FQScZGYAuBw/Uz8QvGgiTZI/AAAAAAAACyY/hm1DP5tgOMw/s800/spritesx_loadbitmap.png)

Hola Alberto!

Me alegro de que resulte interesante!
La verdad es que yo mismo me he sorprendido con PCX2SPR+ por lo rápido que procesa una hoja de sprites. No deja de probar las combinaciones por "fuerza bruta" (aunque esté afinada la elección de elementos a combinar). Explico el algoritmo grosso modo:
"Soluciona" (esto es: encuentra n sprites que cubran todos los píxeles) cada color por separado, y luego prueba las combinaciones entre soluciones de cada color buscando una que minimice el número de sprites en una misma línea. La chicha está en cómo solucionar cada color:
1. Empieza buscando soluciones de 1 sprite. Si para una Y determinada encuentra una, descarta otras con diferentes X en la misma Y (que no aportarían nada a la solución final).
2. Si no las hay, busca soluciones "banda": no cubren todos los píxeles, pero no dejan píxeles a los lados. Igual que antes, descarta múltiples X. Estas bandas se buscan por optimización: ahorran muchísimas combinaciones que se pueden descartar de antemano.
3. Busca fragmentos: cualquier sprite que cubra al menos un píxel. Sólo se darán en sprites de más de 16 píxeles de ancho.
4. Prueba combinaciones de los sprites de los dos puntos anteriores hasta encontrar una solución. Primero lo intenta con dos sprites y, mientras no encuentre solución, va aumentando el tamaño de las combinaciones. Una vez encuentre soluciones, las devuelve todas; son las que luego se combinarán con
el resto de soluciones de los demás colores.


Si ves en el código cualquier cosa que puedas aprovechar, utilízala sin problemas.

Pues sí... Yo soy de línea de comandos porque me resulta más cómodo (de programar y de usar), pero el que prefiera herramientas GUI empieza a tener un abanico bastante majo para elegir ^_^


P.D.: Hace tiempo probé una idea: usar dos sprites ampliados del mismo color (o de colores parecidos) y desplazado un pixel (horizontal, vertical o diagonal) uno respecto al otro. Se conseguían, con sólo dos sprites, un monigote de 33x33 de trazo gordo, pero que disimulaba bastante bien la ampliación.
Lo descarté porque diseñar los sprites a mano era un engorro, pero a lo mejor con una herramienta GUI ad hoc... ::)

gracias!  :)
si más adelante me animo a mejorar esta parte, seria una gran ayuda.
Mi conversor me limita para hacer algo parecido y necesitaría rehacer parte por lo que podría utilizar la lógica de tu sistema.

yo soy más de GUI, pero al trabajar en .net limito su uso solo a win. Me gustaría más adelante pasar a C para poder transportarlo a linux.

esta interesante la idea. Quizás pueda estar interesante para hacer algún FX demoscene.

Saludos!

Buenas.
Os aviso de que he descubierto que PCX2SPR+ no funciona correctamente (y de que no voy a poder subir una versión corregida a corto plazo).
Probando con otras hojas de sprites (por ejemplo, con la del World Rally) he visto que en algunos casos no está encontrando las soluciones con el número mínimo de sprites, por lo que acaba metiendo sprites de más. En concreto, ocurre cuando algún color ocupa más de 16 píxeles de ancho.
Ya lo tengo solucionado, pero ahora en dichos sprites las combinaciones (y, por lo tanto, el tiempo de ejecución) se disparan. Para volver a velocidades aceptables, habría que cambiar el planteamiento y que determinadas combinaciones innecesarias se descarten en los primeros pasos. Es algo que ya tengo en mente cómo hacer, pero como digo no creo que pueda ponerme a ello en breve. :(

Version 1.99c: https://drive.google.com/file/d/0B-dULQ_O2vS4SWd3cGFBV2ttM2M/edit?usp=sharing (https://drive.google.com/file/d/0B-dULQ_O2vS4SWd3cGFBV2ttM2M/edit?usp=sharing)

He reescrito el algoritmo de búsqueda de sprites en un spritesheet. Ahora ya encuentra las soluciones óptimas sin problemas... y sin eternizarse. :)
Por ejemplo, el sprite del coche del World Rally (32x32 a dos colores), que tiene un par de frames que se le atragantan, lo procesa en 5~ minutos en un netbook.

Va con un pequeño programilla ASM de ejemplo para verificar el resultado y para evaluar el número de sprites por scanline (añade una serie de sprites a la derecha para comprobarlo visualmente).

¡Probadlo y me contais!