a976@mindlink.UUCP (Ron Tarrant) (10/25/90)
I'm not sure if the specs are the same for the IBM IFF-anim format as they are for the Amiga, but since it's supposed to be a standard, they should be. Here is a not-very-technical breakdown I did of the Amiga's IFF-anim format. IFF ANIM file: Outline of chunks and their contents. (anything in "double quotes" in the 'Length' column in a literal string and appears in the file as is) LENGTH | DESCRIPTION -------+---------------------------------------------------------- "FORM" | group ID | ULONG | # bytes in file (not including group ID and this ULONG) | "ANIM" | identifies the file as an IFF animation file ------------------------------------------------------------------ "FORM" | second group ID | ULONG | # of bytes in the ILBM Chunk (first frame of anim stored as | an ILBM picture) | "ILBM" | Type ID (this is an InterLeaved BitMap type of IFF) | -------+------------CHUNKS WITHIN THIS FIRST GROUP--------------- | "BMHD" | identifies the next 'chunkette' as the BitMap HeaDer for the | ILBM chunk | ULONG | number of bytes in the BMHD | UWORD | width of image | UWORD | height of image | WORD | pixel position of this image (X) | WORD | pixel position of this image (Y) | UBYTE | number of bitplanes for the image | UBYTE | masking technique | BYTE | compression technique | UBYTE | Pad (must always be zero - '00') | UWORD | transparent color (sometimes) | UBYTE | X Aspect | UBYTE | Y Aspect | WORD | width of source page in pixels | WORD | height of source page in pixels -------+------------------------------------------------------------- | | * The remaining chunks are not in any specific order, or | shouldn't be, so that various types of Anim readers/writers | can be accommodated. | -------+------------------------------------------------------------- "CMAP" | Identifies the chunk as a colour map array. Each colour | register is represented by a triplet of UBYTES, each | representing (in order) Red, Green, Blue. | ULONG | # of values in the Colour Map table (3 times the number of | triplets, or the total # of red and green and blue values) | UBYTE(s) There will a number of UBYTES equal to the immediately | preceeding WORD that stores the actual colour register data. | The elements of red, green, and blue data are stored as | values ranging from 0 to 255 256ths of the colour intensity. | A triplet 0,0,0 represents the lowest intensity (or value) | of all three elements (red, green, and blue), thus we get | black. At the other end of the scale 255,255,255 gives us | white. -------+------------------------------------------------------------- "DPPS" | I suspect this may be a 'modernization' of the DPPV chunk | which allows the reenstatement of the perspective mode in | DPaint. If so, it has little to do with animation. | ULONG | number of bytes in this chunk | VARIOUS| Groups of UBYTES, WORDS, and STRUCTURES describing the | perspective state. This chunk is 110 BYTES long. -------+------------------------------------------------------------- CRNG | Colour RaNGe. Defines a colour range that was set in DPaint | for colour cycling. | ULONG | number of BYTES in this chunk (usually 8) | WORD | Pad. Always zero (for now). This WORD is reserved for future | use. | WORD | Rate. Defines the speed at which the colours will cycle. | WORD | Active. If this WORD is non-zero, then the colours will | cycle if the program into which the file is loaded supports | colour cycling. | UBYTE | Low end of colour cycle range. | UBYTE | High end of colour cycle range. -------+------------------------------------------------------------- DPAN | ? | ULONG | Number of BYTES in this chunk. | VARIOUS| There seems to be a constant number (8) of bytes in this | chunk. Perhaps it has to do with the number of frames or | deltas in an anim file. -------+------------------------------------------------------------- CAMG | ViewPort Mode. | ULONG | number of BYTES in this chunk (always 4) LONG | mode (can be dual playfield, HAM, or, I assume, some other | type of view mode) -------+------------------------------------------------------------- BODY | This chunk, as it's name implies, holds the body of the | image data. The data is organized by scanline. The first | bytes in this chunk will be the zeroth scanline, zeroth | bitplane. The second group of bytes will be the zeroth | scanline, first bitplane, etc. up to the 'n'th bitplane. If | masking is being used (as specified in the BMHD chunk, which | must always appear earlier in the file than the BODY) then | the data for the first scanline is followed by the mask | data. If no compression is specified in the BMHD, then each | of the scanlines is represented by (BMHD-Width divided by | 16) words of data. Otherwise, each row of scanline data is | compressed by the specified algorithm and the number of | words in each stored scanline depends how it was compressed. | The MASK is also compressed in the same fashion if | compression is specified. -------+------------------------------------------------------ -------+------END OF FIRST GROUP------------------------------ -------+------------------------------------------------------ "FORM" | Indentifies the next chunk ID | ULONG | number of bytes in this chunk | "ILBM" | specifies that this chunk is of type ILBM -------+------------------------------------------------------------- "ANHD" | Specifies an Animation Header. | ULONG | the number of bytes in this chunk | UBYTE | operation, how to use the DLTA data that follows while | playing back the anim file. UBYTE | Mask used in XOR operation mode. | UWORD | width of BODY area to be affected by XOR operation mode. | UWORD | height of BODY area to be affected by XOR operation mode. | WORD | X position (top left corner) of screen area to be affected | by XOR operation mode. | WORD | Y position (same as 'X' above) | ULONG | Abstime. This is currently unused, except in AniMagic. It | defines the timing of a frame relative to the timing of the | first frame in the file. The value is given in jiffies | (60ths of a second). | ULONG | Reltime. This is the same as 'abstime' except the timing is | relative to the previous frame in the file, instead of the | first frame. | UBYTE | Interleave. Indicates which frame is to be modified by this | delta. A '0' indicates 2 frames back (for double buffering) | and a '1' indicates the immediately previous frame for | single buffering. At this point there seem to be no | applications which use any other type of buffering method. | UBYTEs | pads (21). This area is reserved for future compression | modes. So far I haven't seen anything show up to use this | except perhaps PageFlipper Plus F/X. -------+------------------------------------------------------------- "DLTA" | identifies a DeLTA chunk. This chunk holds the compressed | data that will be used to change a hidden frame (in the case | of double buffering) into the next frame to be displayed. | ULONG | number of bytes in this chunk. -------+------------------------------------------------------------- Hope this helps. -Ron Tarrant a976@Mindlink.UUCP
bcf@ccadfa.adfa.oz.au (- Chem.) (10/25/90)
Hi, Does anybody know the specifications of an animation file produced by Deluxe Paint Animation for the IBM. I think that it is an IFF form, but I am having a bit of trouble figuring out the forms for the ANIM and the ANIM brush. Cheers, Ben