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
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)

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

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!

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:

(ese sprite en concreto tiene algún pixel que lo hace bastante puñetero )

Por poner un ejemplo, extraería correctamente los del último 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

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...

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.