 |
|
 |
Revistas en papel Commodore World Nº50 |
|
|||||
FICHEROS IFF DESDE BASICPor Fernando Marcos
Coge tu sistema operativo favorito (digamos el Workbench) y conecta el ordenador. Cuando estés en el Workbench propiamente dicho (entorno de ratón), abre un CLI, para poder pedirle al ordenador que haga un par de cositas. Una vez que el CLI esté abierto, dimensiónalo a toda pantalla con el gadget de tamaño (esquina inferior derecha). Localiza un disco donde tengas algún fichero IFF, concretamente del tipo ILBM (Deluxe Paint, Graphicaft, etc) y teclea: TYPE ? Aparecerá una sere de palabras indicando las posibles opciones del comando. Cambia el disco por el de gráficos y teclea el nombre del fichero en cuestión, seguido de "OPT H", para obtener un volcado hexadecimal. El cuadro de la figura 1 es un ejemplo de Deluxe Paint para que puedas estudiarlo sobre la marcha. DIBUJO OPT H DIBUJO OPT H > PRT: (si tienes impresora) Pulsa RETURN. En la pantalla debería aparecer un volcado hexadecimal de lo que contiene el fichero. A la izquierda en hexadecimal y a la derecha en caracteres ASCII. Los bytes que no tienen representación en este formato aparecen como puntos. Puedes parar el listado pulsando la barra de espacios o el botón derecho del ratón. Vamos a ver byte a byte lo que contiene el fichero. Nada más empezar hay cuatro letras, "FORM" (la cabecera del chunk), que indican que están trabajando con un fichero IFF, aunque todavía no sabes de qué tipo es. Los cuatro bytes que siguen indican la longitud total de este trozo del fichero. En realidad, FORM es un chunk, que contiene a su vez todos los chunks del fichero. Por tanto, la longitud de FORM representa la longitud total del fichero menos los ocho primeros bytes. Para calcular la longitud de un chunk, se hace lo siguiente: Primer byte multiplicado por 16777216 Segundo byte multiplicado por 65536 Tercer byte multiplicado por 256 Cuarto byte tal cual Ahora suma todos estos valores. SI entras en el chunk FORM verás que contiene varios chunks a su vez. El primero es el identificador ILBM, que indica que el fichero contiene gráficos. Dado que ILBM no es un chunk, sino una información colocada por convención, lleva una longitud detrás. Lo que sí que encontrarás en otro chunk: el BMHD, abreviatura de Bit Map Header (Cabecera del Bit Map). Este chunk SIEMPRE debe aparecer, ya que contiene información sobre el ancho, el alto, el número de planos y otros datos del dibujo. Si calculas su longitud verás que es de veinte bytes, que se distribuyen así: 2 bytes: Ancho de la imagen 2 bytes: Alto de la imagen 2 bytes: Posición X original dentro de la pantalla 2 bytes: Posición Y original 1 byte: Número de planos 1 byte: Tipo de enmascaramiento (relación con el fondo) 1 byte: Tipo de compresión (ver más adelante) 1 byte: Byte vacío, sin usar. Debe ser cero. 2 bytes: Color transparente. Suele ser cero. 1 byte: Proporción X 1 byte: Proporción Y. Similar al ASPECT del Basic. 2 bytes: Ancho de la pantalla original. 2 bytes: Alto de la pantalla original. Es el tamaño del SCREEN del que se tomó el dibujo. Total 20 bytes Veamos qué es esta parafernalia de bytes. Mira el listado que sacaste antes (o el de la figura 1) y comprueba si coincide con estos cálculos. Observa el chunk BMHD. Le siguen cuatro bytes que tienen al final un $14 (20 en decimal) de momento la longitud coincide con los veinte bytes previstos. Los dos bytes que siguen son $0140 y $00C8, que son respectivamente 320 y 200 en decimal. Este es el tamaño original del dibujo, y según parece, ocupaba toda la pantalal (si era de 320x200, claro). Ahora vienen las coordenadas originales del dibujo, representadas en palabras de 16 bits. Bien, aparecen los bytes $0000 y $0000, que si no me equivoco son 0 en decimal. Esto significa que el dibujo comenzaba en las coordenadas (0,0), es decir, en la esquina superior izquierda. Ahora viene el número de planos que contenía el dibujo, en un solo byte. $05 es cinco planos, calculando, 2 elevado a 5 son 32 colores. Todo esto coincide con un típico dibujo de Deluxe Paint.
Lo siguiente que viene es el enmascaramiento. Hay cuatro tipos de enmascaramiento: 0: No enmascaramiento.
1: La máscara se incluye con la imagen.
2: Partes de la imagen son transparentes.
3: Indica un tipo de máscara especial ("lasso")
El enmascaramiento te dice si un pixel hay que copiarlo o no a su destino, creando efectos de ocultamiento .Si el byte de enmascaramiento es cero, el enmascaramiento no existe, y todo el dibujo aparece tal y como es. Si el byte es 1, en el dibujo, además de incluir la información sobre éste, se incluirá una información extra sobre cómo está codificado el enmascaramiento. Si es 2, uno de los colores del dibujo será transparente. Si colocas ese dibujo encima de otro, verás a través de las zonas de ese color transparente el dibujo que haya debajo. Si el byte es 3, la cosa se complica. Este es un enmascaramiento poco empleado, pero realmente espectacular. Bueno, en nuestro ejemplo el byte de enmascaramiento del dibujo que tenemos entre manos es dos, por lo que algunas partes del dibujo serán transparentes. Ya veremos más tarde qué colores serán transparentes. Ahora viene en un byte el formato de compresión empleado. Si está a cero, la información no está comprimida, pero si no es cero, se identifica con el tipo de compresión empleada. La compresión de ficheros se utiliza para ahorrar espacio en el disco. La más común es la conocida por "CmpByteRun1", farragoso nombre de la rutina creada por Electronic Arts para comprimir información. Más adelante explicaré en qué consiste. Nuestro gráfico en particular está comprimido. Muy bien. Ahora viene un byte, que siempre está a cero. Todavía no tiene utilización, pero está ahí por si alguien lo necesita. Ahora, en dieciséis bits se indica cuál es el color que será transparente en nuestro dibujo. Los bytes contienen el valor cero, y, por tanto, ese será el color el transparente (el color 0 de la paleta). Por último, se incluyen dos bytes que indican la proporción entre X e Y en este dibujo. Así es posible obtener conversiones de formato sin que el dibujo quede aplastado. Incluso se pueden transferir a otros ordenadores... Por fin vienen dos palabras de dieciséis bits que indican el tamaño del SCREEN de donde se obtuvo el dibujo. Verás que vuelve a ser 320x200. COnclusiones: el dibujo (comprimido) es una pantalla completa tomada de una pantalla de 320x200, en 32 colores. No está mal para empezar...
Bien, en un dibujo también hay que definir los colores. Para eso hay otro chunk particular que encontrarás a continuación el CMAP. El formato de los colores cambia bastante entre el Basic y los IFF. Aquí los colores son el nibble alto de un byte. Cada color se define por tres bytes consecutivos. Y el rango de colores varía entre cero y quince. por tanto, un color que sea roja=6, verde=4 y azul=14 sería: $60 $40 $E0 El número de colores se conoce de antes (viene en el Chunk BMHD). Por tanto, habrá que comprobar que el número de colroes esté bien. Para ello, se toma la longitud del chunk (como al principio), y se divide entre tres, para obtener el número de colores. si no coincide, el fichero está corrupto ("mangled" dice el Deluxe Paint...). Bien, en el ejemplo la pantalla es de 32 colores. Y el chunk indica una longitud de $60 bytes, es decir, 96 bytes. A tres bytes por color, 96/3 da los 32 colores supuestos. En realidad, no es necesario efectuar esta comprobación, porque no creo que nadie tenga la mala uva de poner a propósito chunks cambiados para protegerlos, pero ya se sabe... Ahora vienen una serie de chunks no-estándar que no afectan al resultado final. Hay uno particular de Deluxe Paint, llamado DPPV, y luego toro que contiene la definición del ciclo de colores, llamado CRNG (Color Range). Tampoco interesan. El siguiente chunk sí que interesa: se llama BODY, y contiene la información gráfica propiamente dicha. Aquí es donde van los planos del dibujo que forman la imagen. Su estructura se explica en el siguiente punto. Ahora que has terminado de ver cómo es una cabecera tipica ILBM, podrás estudiar algunos de los puntos que no se explicaron antes.
El byte de compresión indica el método de compresión utilizado. Normalmente es cero o uno, cero para no-compresión, y uno para CmpByteRun. Si tú mismo te crear un formato de compresión eficaz, no hay problema para que le asignes, por ejemplo, el número dos y grabes con él tus dibujos favoritos... pero no esperes que luego Deluxe Paint lo reconozca. Bien, vamos a ver el formato del dibujo. Recuerda que la pantalla del Amiga está formada por varios planos que codifican los colores. Por tanto, habrá que cargar cada plano. Lo más lógico hubiera sido grabar plano tras plano, para que quede en la memoria de forma secuencial. Aunque éste sea el método más cómodo, no se emplea porque tiene un inconveniente: Si se estropea parte de un fichero, no se pueden cargar los planos que hay detrás del error, por lo que el dibujo queda desfigurado. ¿Qué es lo que se hace entonces? Muy fácil, se graba fila por fila la pantalla completa, con sus cinco planos, en este formato: Línea 0, plano 0 Línea 0, plano 1 Línea 0, plano 2, etc., hasta terminar todos los planos. Línea 1, plano 0 Línea 1, plano 1. Y así hasta el final. La ventaja de este método es que si ocurre un error de disco, el dibujo será recuperable hasta la línea donde aparezca el error, porque esa información ya está en pantalla. En la práctica, cargamos 40 bytes si la pantalla es de 320 puntos horizontales (80 si es de 640), lo colocamos en el plano 0, cargamos otros 40, los colocamos en el plano 1, y así hasta el final. El problema viene cuando el fichero es´ta comprimido. En este caso, se comprime CADA FILA antes de grabarla a disco. Para ello, se lee el primer byte de la fila, (n) y se actúa de este modo: Si n está entre 0 y 127, se lee el siguiente byte del disco y se copian literalmente los n + 1 bytes siguientes a memoria. Si n está entre -1 y -127 se lee el siguiente byte y se copia -n + 1 veces en la memoria. Si n es -128, no se hace nada. Una vez terminada esta descompresión parcial se lee otro byte N y se vuelve a repetir la operación hasta se termine con toda la fila. Luego se comienza con el siguiente plano de esa fila, hasta terminar con todos los planos y pasar a la siguiente fila.
Admito que leer las cabeceras IFF a mano es una labor incluso divertida, pero cuando se llevan unas cuantas cabeceras leídas, el trabajillo empieza a cansar notablemente. Estaba yo ya harto de hacerlo cuando recordé (una vez más) que para eso se diseñaron los ordenadores. El resultado ha sido la rutina IFF-DUMP. Esta rutina deja al desnudo cualquier fichero ILBM que se le pase por delante. Al ejecutarla pide el nombre del fichero, y la salida por pantalla o por impresora. Nos dará toda la información que hasta ahroa hemos obtenido a mano, incluido un listado de todos los colores empleados. El segundo programa se llama IFF-VIEW. Permite tomar cualquier fichero gráfico ILBM (menos los que sean HAM) y mostarlo en pantalla, cualquiera que sea su formato interno (comprimido o no comprimido). Pero hace algo más: de la pantalla obtenida se pueden "recortar" pedazos y luego grabarlos a disco en formato MOB, para utilizarlos después en otros programas. Su funcionamiento es muy sencillo: al arrancar pide el nombre del fichero ILBM. Después lee sus cabeceras y genera un screen y un window que se ajusten a su formato. Esto es sencillo conociendo el formato de la pantalla del Amiga (hay una explicación completa en el artículo "Conoce mejor a tu Amiga", publicado en el número 48 página 35). Si no lo has leído (no sabes lo que te pierdes), lo que se hace en realidad es "escribir" la pantalla meidante POKEs directos a memoria. Aquí surge una pequeña pega.
El Amiga me dio otra sorpresa de las suyas mientras escribía estos programas. Creé una pantalla de 320x200 en 32 colores, para trabajar con ella directamente a base de POKEs. Quise poner el primer byte de cada plano encendido, para probar. Así que calculé la longitud de la pantalla en bytes (40 bytes por fila por 200 filas = 8000 bytes), y luego deduje la posición del resto de los planos a partir de ahí. Si el primer plano estaba en la posición 20000, el segundo estaría en la 28000, el tercero en la 36000, etc. Hice un POKE al primer plano, al segundo, etc. Y todo iba bien. Pero al llegar al quinto plano, al hacer POKE todo se me fue a la porra. Como al principio, fue porque supuse que los planos eran consecutivos en memoria, pero en realidad no era así .No me quedaba más remedio que dejarlo para otro momento. Pero se me ocurrió ver si los vectores que había a continuación apuntaban a los otros planos. ¡Eureka!, así es. Los vectores 19022, 19026, 19030, 19034 y 19038 apuntan a los planos de una pantalla de 32 colores. Lo que más interesa del programa es su habilidad para crear MOBs que se puedan cargar con enorme facilidad desde Basic. Y con muy poco esfuerzo pueden convertirse en sprites. Bien, vamos a ver cómo se hace. Primero, carga el dibujo. Cuando la zona que te interese esté en pantalla, pulsa ESC y espera a oír el beep que indique que se ha terminado de cargar esa línea de pantalla. Ahora, con el ratón, apunta a la esquina superior izquierda del dibujo, y, con el botón pulsado, muévelo hasta la otra esquina. Verás cómo la zona de dibujo que quieres "llevarte" se pone en inverso. Suelta el botón. Si no te gusta la toma, la puedes repetir cuantas veces quieras. Cuando estés contento, pulsa la barra de espacios y el programa te pedirá un nombre de fichero. Se grabará en formato MOB. Para cargarlo, nada más fácil que teclear en tu programa estas líneas. OPEN "nombre" FOR INPUT AS 1 OBJECT.SHAPE NoObjeto,INPUT$(LOF(1),1) CLOSE 1 Y ya está. Ahora lo puedes colocar en pantalla con OBJECT.X y OBJECT.Y, moverlo, encenderlo, apagarlo, etc. Además, carga a GRAN velocidad. Dado que esta toma de objetos (sobre todo si la pantalla es de muchos colores y los objetos van a ser muy grandes) puede ocupar muchísima memoria, es recomendable hacer un CLEAR antes de cargar el programa, para dejar memoria disponible. De todas formas, he incluido una pequeña ayuda. Si después de seleccionar la zona que quieres tomar deseas ver la memoria que va a ocupar, pulsa HELP. Aparecerá en la esquina superior izquierda el número de bytes aproximados que va a ocupar. Y ten en cuenta, claro, que un objeto de 32 colores debe ser representado en un screen de 32 colores, y que la paleta NO va en la definición del mob, por lo que debes definirla de nuevo "a mano" en el programa que crees. El último programa se llama IFF-TRANSFER, y sirve para pasar una pantalla estándar del Basic a fichero IFF: Genera un fichero de 640x256 de alto, a cuatro colores, Recuerda además que lo hacen en formato no-comprimido, para aumentar la velocidad. Bien, ya sabes cómo son los ficheros IFF por dentro. Ahora sigue investigando por tu cuenta... ¡Hay mucho que ver!
|
| Envía esta página web a un amigo: Esta opción está desactivada temporalmente, rogamos disculpen las molestias |
|
