Img2CPC

CEZ Team presenta...

Img2CPC

Convierte imágenes en casi cualquier formato (gif, jpg, bmp, png, tiff...) a definiciones utilizables desde z88dk.

Permite el recortado de imágenes (indicandole ancho y alto de tile). También se le puede pasar una lista de archivos (incluso indicando wildcards, como * y ?).

Hace falta el Framework de .NET 2.0

Os pongo aquí el readme.txt:

Código: Seleccionar todo

Img2CPC
(c) CEZ Team 2007

If you liked this program, drop an email at: augusto.ruiz@gmail.com
-------------------------------------------------------------------

Usage:

Img2CPC [/w=width] [/h=height] [/g] [/bn=tileBaseName] [/m=mode] files

   w   Tile Width. If not specified, it will process the
      whole image width.

   h   Tile Height. If not specified, it will process the
      whole image height.

   g   If specified, it will generate one bmp file per tile.

   bn   Base name to be used for asm labels.

   m   Graphic Mode (0,1,2).

   files   List of files to process. Wildcards can be used (*.png)

ENJOY!

[Artaburu]

¡Genial! ¡Vamos a verlo!

Lo bueno es usar la opción /g para hacer pruebas, ya que te generará un fichero .bmp por tile que extraiga, con la paleta indicada.

Por cierto, que no lo he comentado, se le puede especificar la paleta en el fichero .config que acompaña al ejecutable. Es un xml, así que no debería haber problema para editarlo.

Lo que quiero hacer es que genere también máscaras si le dices que son transparentes. Lo que no tengo claro es cómo hacerlo. Supongo que la máscara será una definición similar a la del sprite, pero simplemente indicando pixels con valor 0 para los opacos y 0xF para los transparentes (en modo 0, en modo 1 sería un 0x3, y en modo 2 un 0x1), no?

[Artaburu]

Eso es, la máscara define los transparentes con el color más alto (según el modo) y los opacos con 0. ¡Si lo metes ya será genial porque es un coñazo andar haciendo las máscaras!

Pues a ver si esta tarde/noche...

Nueva versión, con soporte para máscaras.

Para que genere máscaras, hay que pasarle /t

Para más información, leer el readme.txt, o ejecutad el exe sin parámetros.

Saludos!

Pon también el readme en ejpañol!!

Por cierto, chapeaú con la herramienta, agus!

Con el readme en español.

Muy buena la herramienta, sí señor. Yo siempre he capturado los gráficos directamente de la memoria del emulador, pero este invento tuyo, que hasta calcula las máscaras, resulta mucho más cómodo. Enhorabuena.

Una duda...

¿Merecería la pena ponerle un GUI para que se pueda ver cómo va a partir las imágenes, etc?

Yo la veo bien así. Ahora bien, si quieres mejorala, adelante. No te cortes, por favor.

Lo nuevo: Posibilidad de indicarle el nombre del fichero generado (con /o=Fichero), y la posibilidad de que genere una tabla de lookup con valores inversos para dar la vuelta a los sprites dinámicamente (/f). Esta última se puede utilizar sola, sin pasarle ficheros.

Para lo que vale esa tabla de lookup es para el caso en el que tienes el sprite en memoria, almacenado con el formato del modo de pantalla que se le indique al programa (por defecto modo 0, ya sabes), y si quieres pintar el sprite "mirando para el otro lado", lo "único" que habría que hacer es en vez de poner en la posición de memoria del pixel el valor del sprite, poner el valor de la tabla para el valor del sprite.

Es decir, si tienes dos pixels cuyo byte es 0xF, pintarías en la pantalla el byte TABLA[0xF].

Si esto se hace además recorriendo los datos del sprite del revés (o decrementando la posición en la pantalla en vez de incrementándola), pintarías el sprite dado la vuelta...

Uf, vaya lío que me he montao yo solo...

Hombre si le metes un gui de esos mejor, así no hay que andarse con comandos. Pero lo que veas

[Artaburu]

Yo ne me he enterado mucho de eso del sprite girado, qué es, que genera el código para 2 sprites y el girado se lee al reves?

Yo ne me he enterado mucho de eso del sprite girado, qué es, que genera el código para 2 sprites y el girado se lee al reves?

No, la idea es tener en memoria sólo un sprite, y tener dos rutinas de pintado. Para pintarlo "al derecho", se pintaría tal cual se hace ahora, es decir, lees el sprite incrementando la posición (en horizontal) y pintas en pantalla incrementando la dirección de memoria (en horizontal también).

Pero para pintarlo "al revés", lees el sprite incrementando la posición (en horizontal) y pintas en la pantalla decrementando la dirección de memoria (en horizontal). Lo que pasa es que si lo haces así, en modo 0, cada byte tiene dos pixeles, y los dos pixeles estarían colocados "al derecho", con lo que se te va todo a hacer puñetas.

Para eso es la tabla. Lo que tiene son los 256 valores posibles que puede tener un byte, y almacena el valor que tendrían esos dos pixels dados la vuelta (4 si es modo 1, y 8 si es modo 2). Con lo que para pintar, en vez de pintar el byte del sprite, usas ese byte como índice en la tabla, y pintas esos dos pixeles dados la vuelta.

Lo he liado más, o ahora se entiende?