                        [Images & Graphics Header]

Animator Pro File Formats

This chapter details each of the file formats defined by Animator Pro.
Formats supported by Animator Pro but defined by another party, such as GIF
and TIFF files, are not described in this document.

The files created by Autodesk Animator Pro are a superset of those created
by the original Autodesk Animator. In some cases the Animator Pro formats
are identical with the older Animator format. In other cases, new data
fields or data compression techniques have been added to the file.

All two-byte and four-byte data values in Animator Pro files are stored in
Intel-style order, the same as they would appear in memory on an 80x86
machine.

Common Hierarchial Chunked File Structure

In general, Animator Pro files contain one or more chunks of information.
Conceptually, a chunk is a combination of control information and data. The
most common Animator Pro file format is a header structure followed by
hierarchial data chunks.

Every chunk begins with a header of at least 6 bytes. The first four bytes
contain the length of the chunk (including the header itself, and also
including the length of all subordinate chunks, if any). The next two bytes
are an identifier word which describes the type of data in the chunk. Some
chunks have headers longer than six bytes, but the size and identifier
fields always occupy the first six bytes of the header.

The Animator Pro animation file is a good example of a hierarchial chunked
file structure. The data in an animation file is arranged as follows:

animation file:

   * optional prefix chunk:
        o settings chunk
        o cel placement chunk
   * frame 1 chunk:
        o postage stamp chunk: postage stamp data
        o color palette chunk
        o pixel data chunk
   * frame 2 chunk:
        o pixel data chunk
   * frame 3 chunk:
        o color palette chunk
        o pixel data chunk
   * frame 4 chunk:
        o color palette chunk
   * ring frame chunk:
        o color palette chunk
        o pixel data chunk

It is possible that new types of chunks not described in this document will
be added to animation files in the future. We recommend that you quietly
ignore unknown chunk types you encounter during animation playback. The
size fields in the chunk headers make it easy to skip an entire
unrecognized chunk.

FLC - Animator Pro Flic Files

This is the main animation file format created by Animator Pro. The file
contains a 128-byte header, followed by an optional prefix chunk, followed
by one or more frame chunks.

The prefix chunk, if present, contains Animator Pro settings information,
CEL placement information, and other auxiliary data.

A frame chunk exists for each frame in the animation. In addition, a ring
frame follows all the animation frames. Each frame chunk contains color
palette information and/or pixel data.

The ring frame contains delta-compressed information to loop from the last
frame of the flic back to the first. It can be helpful to think of the ring
frame as a copy of the first frame, compressed in a different way. All flic
files will contain a ring frame, including a single-frame flic.

The FLC file header

A FLC file begins with a 128-byte header, described below. All lengths and
offsets are in bytes. All values stored in the header fields are unsigned.

Offset  Length  Name         Description

  0       4     size         The size of the entire animation file,
                             including this file header.

  4       2     magic        File format identifier. Always hex AF12.

  6       2     frames       Number of frames in the flic.  This
                             count does not include the ring frame.
                             FLC files have a maximum length of 4000
                             frames.

  8       2     width        Screen width in pixels.

  10      2     height       Screen height in pixels.

  12      2     depth        Bits per pixel (always 8).

  14      2     flags        Set to hex 0003 after ring frame is
                             written and flic header is updated.
                             This indicates that the file was properly
                             finished and closed.

  16      4     speed        Number of milliseconds to delay between
                             each frame during playback.

  20      2     reserved     Unused word, set to 0.

  22      4     created      The MSDOS-formatted date and time of the
                             file's creation.

  26      4     creator      The serial number of the Animator Pro
                             program used to create the file.  If the
                             file was created by some other program
                             using the FlicLib development kit, this
                             value is hex 464C4942 ("FLIB").

  30      4     updated      The MSDOS-formatted date and time of the
                             file's most recent update.

  34      4     updater      Indicates who last updated the file.  See
                             the description of creator.

  38      2     aspectx      The x-axis aspect ratio at which the file
                             was created.

  40      2     aspecty      The y-axis aspect ratio at which the file
                             was created. Most often, the x:y aspect ratio
                             will be 1:1.  A 320x200 flic has a ratio of
                             6:5.

  42      38    reserved     Unused space, set to zeroes.

  80      4     oframe1      Offset from the beginning of the file to the
                             first animation frame chunk.

  84      4     oframe2      Offset from the beginning of the file to
                             the second animation frame chunk.  This value
                             is used when looping from the ring frame back
                             to the second frame during playback.

  88      40    reserved     Unused space, set to zeroes.

The FLC prefix chunk

An optional prefix chunk may immediately follow the animation file header.
This chunk is used to store auxiliary data which is not directly involved
in the animation playback. The prefix chunk starts with a 16-byte header
(identical in structure to a frame header), as follows:

Offset  Length  Name         Description

  0       4     size         The size of the prefix chunk, including
                             this header and all subordinate chunks
                             that follow.

  4       2     type         Prefix chunk identifier. Always hex F100.

  6       2     chunks       Number of subordinate chunks in the
                             prefix chunk.

  8       8     reserved     Unused space, set to zeroes.

To determine whether a prefix chunk is present, read the 16-byte header
following the file header. If the type value is hex F100, it's a prefix
chunk. If the value is hex F1FA it's the first frame chunk, and no prefix
chunk exists.

Note

Programs other than Animator Pro should never need to create flic files
that contain a prefix chunk. Programs reading a flic file should skip the
prefix chunk by using the size value in the prefix header to read and
discard the prefix, or by seeking directly to the first frame using the
oframe1 field from the file header.

The FLC frame chunks

Frame chunks contain the pixel and color data for the animation. A frame
chunk may contain multiple subordinate chunks, each containing a different
type of data for the current frame. Each frame chunk starts with a 16-byte
header that describes the contents of the frame:

Offset  Length  Name         Description

  0       4     size         The size of the frame chunk, including this
                             header and all subordinate chunks that follow.

  4       2     type         Frame chunk identifier. Always hex F1FA.

  6       2     chunks       Number of subordinate chunks in the
                             frame chunk.

  8       8     reserved     Unused space, set to zeroes.

Immediately following the frame header are the frame's subordinate data
chunks. When the chunks count in the frame header is zero, it indicates
that this frame is identical to the previous frame. This implies that no
change is made to the screen or color palette, but the appropriate delay is
still inserted during playback.

Each data chunk within a frame chunk is formatted as follows:

Offset  Length  Name         Description

  0       4     size         The size of the chunk, including this header.

  4       2     type         Data type identifier.

  6    (size-6) data         The color or pixel data.

The type values in the chunk headers indicate what type of graphics data
the chunk contains and which compression method was used to encode the
data. The following values (and their associated mnemonic names) are
currently found in frame data chunks:

Value     Name        Description

  4    FLI_COLOR256   256-level color palette info
  7    FLI_SS2        Word-oriented delta compression
  11   FLI_COLOR      64-level color palette info
  12   FLI_LC         Byte-oriented delta compression
  13   FLI_BLACK      Entire frame is color index 0
  15   FLI_BRUN       Byte run length compression
  16   FLI_COPY       No compression
  18   FLI_PSTAMP     Postage stamp sized image

The following sections describe each of these data encoding methods in
detail.

Chunk Type 4 (FLI_COLOR256) - 256-Level Color

The data in this chunk is organized in packets. The first word following
the chunk header is a count of the number of packets in the chunk. Each
packet consists of a one-byte color index skip count, a one-byte color
count and three bytes of color information for each color defined.

At the start of the chunk, the color index is assumed to be zero. Before
processing any colors in a packet, the color index skip count is added to
the current color index. The number of colors defined in the packet is
retrieved. A zero in this byte indicates 256 colors follow. The three bytes
for each color define the red, green, and blue components of the color in
that order. Each component can range from 0 (off) to 255 (full on). The
data to change colors 2,7,8, and 9 would appear as follows:

     2                      ; two packets
     2,1,r,g,b              ; skip 2, change 1
     4,3,r,g,b,r,g,b,r,g,b  ; skip 4, change 3

Chunk Type 11 (FLI_COLOR) - 64-Level Color

This chunk is identical to FLI_COLOR256 except that the values for the red,
green and blue components are in the range of 0-63 instead of 0-255.

Chunk Type 13 (FLI_BLACK) - No Data

This chunk has no data following the header. All pixels in the frame are
set to color index 0.

Chunk Type 16 (FLI_COPY) - No Compression

This chunk contains an uncompressed image of the frame. The number of
pixels following the chunk header is exactly the width of the animation
times the height of the animation. The data starts in the upper left corner
with pixels copied from left to right and then top to bottom. This type of
chunk is created when the preferred compression method (SS2 or BRUN)
generates more data than the uncompressed frame image; a relatively rare
situation.

Chunk Type 15 (FLI_BRUN) - Byte Run Length Compression

This chunk contains the entire image in a compressed format. Usually this
chunk is used in the first frame of an animation, or within a postage stamp
image chunk.

The data is organized in lines. Each line contains packets of compressed
pixels. The first line is at the top of the animation, followed by
subsequent lines moving downward. The number of lines in this chunk is
given by the height of the animation.

The first byte of each line is a count of packets in the line. This value
is ignored, it is a holdover from the original Animator. It is possible to
generate more than 255 packets on a line. The width of the animation is now
used to drive the decoding of packets on a line; continue reading and
processing packets until width pixels have been processed, then proceed to
the next line.

Each packet consist of a type/size byte, followed by one or more pixels. If
the packet type is negative it is a count of pixels to be copied from the
packet to the animation image. If the packet type is positive it contains a
single pixel which is to be replicated; the absolute value of the packet
type is the number of times the pixel is to be replicated.

Chunk Type 12 (FLI_LC) - Byte Aligned Delta Compression

This chunk contains the differences between the previous frame and this
frame. This compression method was used by the original Animator, but is
not created by Animator Pro. This type of chunk can appear in an Animator
Pro file, however, if the file was originally created by Animator, then
some (but not all) frames were modified using Animator Pro.

The first 16-bit word following the chunk header contains the position of
the first line in the chunk. This is a count of lines (down from the top of
the image) which are unchanged from the prior frame. The second 16-bit word
contains the number of lines in the chunk. The data for the lines follows
these two words.

Each line begins with two bytes. The first byte contains the starting x
position of the data on the line, and the second byte the number of packets
for the line. Unlike BRUN compression, the packet count is significant
(because this compression method is only used on 320x200 flics).

Each packet consists of a single byte column skip, followed by a packet
type/size byte. If the packet type is positive it is a count of pixels to
be copied from the packet to the animation image. If the packet type is
negative it contains a single pixel which is to be replicated; the absolute
value of the packet type gives the number of times the pixel is to be
replicated.

Note

The negative/positive meaning of the packet type bytes in LC compression is
reversed from that used in BRUN compression. This gives better performance
during playback.

Chunk Type 7 (FLI_SS2) - Word Aligned Delta Compression

This format contains the differences between consecutive frames. This is
the format most often used by Animator Pro for frames other than the first
frame of an animation. It is similar to the line coded delta (LC)
compression, but is word oriented instead of byte oriented. The data is
organized into lines and each line is organized into packets.

The first word in the data following the chunk header contains the number
of lines in the chunk. Each line can begin with some optional words that
are used to skip lines and set the last byte in the line for animations
with odd widths. These optional words are followed by a count of the
packets in the line. The line count does not include skipped lines.

The high order two bits of the word is used to determine the contents of
the word.

     Bit 15  Bit 14       Meaning

       0      0           The word contains the packet count.  The
                          packets follow this word.  The packet count
                          can be zero; this occurs when only the last
                          pixel on a line changes.

       1      0           The low order byte is to be stored in the
                          last byte of the current line.  The packet
                          count always follows this word.

       1      1           The word contains a line skip count.  The
                          number of lines skipped is given by the
                          absolute value of the word.  This word can
                          be followed by more skip counts, by a last
                          byte word, or by the packet count.

The packets in each line are similar to the packets for the line coded
chunk. The first byte of each packet is a column skip count. The second
byte is a packet type. If the packet type is positive, the packet type is a
count of words to be copied from the packet to the animation image. If the
packet type is negative, the packet contains one more word which is to be
replicated. The absolute value of the packet type gives the number of times
the word is to be replicated. The high and low order byte in the replicated
word do not necessarily have the same value.

Chunk Type 18 (FLI_PSTAMP) - Postage Stamp Image

This chunk type holds a postage stamp -- a reduced-size image -- of the
frame. It generally appears only in the first frame chunk within a flic
file.

When creating a postage stamp, Animator Pro considers the ideal size to be
100x63 pixels. The actual size will vary as needed to maintain the same
aspect ratio as the original.

The pixels in a postage stamp image are mapped into a six-cube color space,
regardless of the color palette settings for the full frame image. A
six-cube color space is formed as follows:

     start at palette entry 0
     for red = 0 thru 5
          for green = 0 thru 5
               for blue = 0 thru 5
                    palette_red   = (red   * 256)/6
                    palette_green = (green * 256)/6
                    palette_blue  = (blue  * 256)/6
                    move to next palette entry
               end for blue
          end for green
     end for red

Any arbitrary rgb value (where each component is in the range of 0-255) can
be mapped into the six-cube space using the formula:

((6*red)/256)*36 + ((6*green)/256)*6 + ((6*blue)/256)

When a frame data chunk has been identified as a postage stamp, the header
for the chunk contains more fields than just size and type. The full
postage stamp chunk header is defined as follows:

Offset  Length  Name         Description

  0       4     size         The size of the postage stamp chunk,
                             including this header.

  4       2     type         Postage stamp identifier; always 18.

  6       2     height       Height of the postage stamp image, in
                             pixels.

  8       2     width        Width of the postage stamp image, in
                             pixels.

  10      2     xlate        Color translation type; always 1,
                             indicating six-cube color space.

Immediately following this header is the postage stamp data. The data is
formatted as a chunk with standard size/type header. The type will be one
of:

     Value    Name           Description

     15     FPS_BRUN         Byte run length compression
     16     FPS_COPY         No compression
     18     FPS_XLAT256      Six-cube color xlate table

The FPS_BRUN and FPS_COPY types are identical to the FLI_BRUN and FLI_COPY
encoding methods described above.

The FPS_XLAT256 type indicates that the chunk contains a 256-byte color
translation table instead of pixel data. To process this type of postage
stamp, read the pixel data for the full-sized frame image, and translate
its pixels into six-cube space using a lookup in the 256-byte color
translation table. This type of postage stamp appears when the size of the
animation frames is smaller than the standard 100x63 postage stamp size.

FLI - Original Animator Flic Files

This animation file format is limited to 320x200 resolution. It is the main
animation file format of the original Animator, and is still used by
Animator Pro for creating 320x200 animations. The file structure is very
similar to that of a FLC file. A FLI file does not contain a prefix chunk,
and does not use FLI_PSTAMP or FLI_SS2 data encoding in the frame chunks.

The FLI file header

The file header for a FLI file is a subset of the FLC file header. It is
defined as follows:

Offset  Length  Name         Description

  0       4     size         The size of the entire animation file,
                             including this file header.

  4       2     magic        File format identifier. Always hex AF11.

  6       2     frames       Number of frames in the flic. This count
                             does not include the ring frame.  FLI files
                             have a maximum length of 4000 frames.

  8       2     width        Screen width in pixels. This is always
                             320 in a FLI file.

  10      2     height       Screen height in pixels. This is always
                             200 in a FLI file.

  12      2     depth        Bits per pixel (always 8).

  14      2     flags        Always zero in a FLI file.

  16      2     speed        Number of jiffies to delay between each
                             frame during playback.  A jiffy is 1/70
                             of a second.

  18      110   reserved     Unused space, set to zeroes.

The FLI frame chunks

One or more frame chunks immediately follow the FLI file header. The frame
chunks in a FLI file are identical to those in a FLC file, except that
postage stamp image (FLI_PSTAMP) and word-runlength-compression (FLI_SS2)
data chunks never appear in FLI files.

CEL - Animation Cel Files

CEL files contain one or more frames of image data. Both Animator Pro and
the original Animator produce CEL files, but each uses a different file
format.

To process a CEL file for input, read the first 2 bytes of the file. If
they are hex 9119, the file is an original Animator CEL file. If the first
two bytes are not 9119, it is an Animator Pro CEL file.

Animator Pro CEL Files

An Animator Pro CEL file is identical to a FLC file in all respects. A CEL
file should have a Celdata chunk in the file prefix chunk which describes
the x,y placement of the CEL. If the Celdata placement chunk is not
present, assume a placement of 0,0.

Original Animator CEL Files

The original Animator also produced CEL files. These were still-picture
files, not the multi-frame files Animator Pro now uses. A CEL file from the
original Animator is identical to a PIC file from the original Animator in
all respects.

PIC - Picture Files

PIC files contain still images in an uncompressed format. Both the original
Animator and Animator Pro produce PIC files. The file formats are
different; Animator Pro produces a hierarchial chunked file, while the
original Animator file is a simpler fixed format. These formats are
detailed in the following sections.

To process a PIC file for input, read the first 2 bytes of the file. If
they are hex 9119, the file is an original Animator PIC format file. If the
first two bytes are not 9119, it is an Animator Pro PIC file.

Animator Pro PIC Files

Animator Pro uses this format to store a single-frame picture image or
bitmap. This format description applies to both PIC and MSK files. The file
begins with a 64-byte header defined as follows:

Offset  Length  Name         Description

  0       4     size         The size of the file, including this header.

  4       2     magic        File format identifier. Always hex 9500.

  6       2     width        The width of the image, in pixels.

  8       2     height       The height of the image, in pixels.

  10      2     xcoord       The X coordinate; typically zero.  (See
                             note below).

  12      2     ycoord       The Y coordinate; typically zero.  (See
                             note below).

  14      4     userid       An arbitrary 4-byte value; generally
                             zero.  Do not count on any particular
                             value in this field.  Set this field to
                             zero when creating a file.

  18      1     depth        The number of bits per pixel. This is 8
                             for PIC files and 1 for MSK files.

  19      45    reserved     Unused space; set to zeroes.

Note

The xcoord and ycoord values in a PIC file header will typically be zero.
Non-zero values indicate that the file contains a rectangle from within a
larger picture. In this case, the xcoord and ycoord values represent the
relation of the saved rectangle to the full image. These values can be
safely ignored for most purposes.

Following the file header are the data chunks for the image. Each data
chunk within a PIC or MSK file is formatted as follows:

Offset  Length  Name         Description

  0       4     size         The size of the chunk, including this header.

  4       2     type         Data type identifier.

  6    (size-6) data         The color or pixel data.

The type values in the chunk headers indicate what type of graphics data
the chunk contains. The following values (and their associated mnemonic
names) are currently found in PIC/MSK data chunks:

     Value    Name            Description

     0    PIC_CMAP            Color palette info
     1    PIC_BYTEPIXELS      Byte-per-pixel image data
     2    PIC_BITPIXELS       Bit-per-pixel mask data

In a PIC_CMAP chunk, the first 2-byte word is a version code; currently
this is set to zero. Following the version word are all 256 palette entries
in rgbrgb... order. Each of the r, g, and b components is a single byte in
the range of 0-255. This type of chunk appears in PIC files; there will
generally be no color map chunk in a MSK file.

In a PIC_BYTEPIXELS chunk, the image data appears immediately following the
6-byte chunk header. The data is stored as one byte per pixel, in
left-to-right, topD to-bottom sequence. This type of chunk appears in PIC
files.

In a PIC_BITPIXELS chunk, the bitmap data appears immediately following the
6-byte chunk header. The data is stored as bits packed into bytes such that
the leftmost bits appear in the high-order positions of each byte. The bits
are stored in left-to-right, top-toD bottom sequence. When the width of the
bitmap is not a multiple of 8, there will be unused bits in the lowD order
positions of the last byte on each line. The number of bytes per line is
((width+7)/8). This type of chunk appears in MSK files.

Original Animator PIC Files

The original Animator uses this format to store a single-frame picture
image. This format description applies to both PIC and CEL files. The file
begins with a 32 byte header, as follows:

Offset  Length  Name         Description

  0       2     type         File type identifier.  Always hex 9119.

  2       2     width        Width of image.  Always 320 in a PIC
                             file; may be any value in a CEL file.

  4       2     height       Height of image.  Always 200 in a PIC
                             file; may be any value in a CEL file.

  6       2     xcoord       X coordinate for upper left corner of
                             the image.  Always zero in a PIC file;
                             may be non-zero in a CEL file.

  8       2     ycoord       Y coordinate for upper left corner of
                             the image.  Always zero in a PIC file;
                             may be non-zero in a CEL file.

  10      1     depth        Number of bits per pixel; always 8.

  11      1     compress     Compression flag; always zero.

  12      4     datasize     Size of the image data in bytes.

  16      16    reserved     Unused space; set to zeroes.

Immediately following the header is the color map. It contains all 256
palette entries in rgbrgb... order. Each of the r, g, and b components is a
single byte in the range of 0-63. Following the color palette is the image
data, one byte per pixel. The image data is stored in left-to-right,
top-to-bottom sequence.

MSK - Mask Data Files

MSK files contain a bitmap image. Both Animator Pro and the original
Animator produce MSK files, but the formats are different.

To process a MSK file for input, check the file size. If it is exactly 8000
bytes, the file is an original Animator MSK file. If the file is any other
size, it is an Animator Pro MSK file.

Animator Pro MSK Files

An Animator Pro MSK file is identical to an Animator Pro PIC file. It will
have a pixel depth of 1.

Original Animator MSK Files

A MSK file created by the original Animator is exactly 8000 bytes long.
There is no file header or other control information in the file. It
contains the image bit map, 1 bit per pixel, with the leftmost pixels
packed into the high order bits of each byte. The size of the image is
fixed at 320x200. The image is stored left-to-right, top-to-bottom.

COL - Color Map Files

A COL file stores the rgb values for entries in the color palette. Both
Animator Pro and the original Animator produce COL files, but the formats
are different.

To process a COL file for input, check the file size. If it is exactly 768
bytes, the file is an original Animator COL file. If the file is any other
size, it is an Animator Pro COL file.

Animator Pro COL Files

An Animator Pro COL file stores color palette information. The file begins
with an 8-byte header defined as follows:

Offset  Length  Name         Description

  0       4     size         The size of the file, including this header.

  4       2     magic        File format identifier. Always hex B123.

  6       2     version      The version of color storage format.
                             Currently set to zero, indicating
                             256-level color data in each r,g,b
                             component.

Following the file header are palette entries in rgbrgb... order. Each of
the r, g, and b components is a single byte in the range of 0-255.
Generally, there will be data for 256 palette entries, but this cannot be
assumed. The actual number of palette entries is ((size-8)/3); if this
value is not an even multiple of three, the file is corrupted.

Original Animator COL Files

A COL file created by the original Animator is exactly 768 bytes long.
There is no file header or other control information in the file. The rgb
values for all 256 palette entries is stored in rgbrgb... sequence. Each of
the r, g, and b values is in the range of 0-63.

PLY - Polygon Files

A PLY file holds a set of points that describe a polygon. Both Animator Pro
and the original Animator create PLY files. The file format is the same for
both.

A PLY file starts with an 8-byte header, as follows:

Offset  Length  Name         Description

  0       2     points       Count of points in the file.

  2       4     reserved     Unused space; set to zero.

  6       1     closed       Closed-shape flag.  If 1, there is an
                             implied connection between the last point
                             and the first.  If zero, the shape is not
                             closed.

  7       1     magic        File format identifier. Always hex 99.

The points data follows the file header. Each point is described with three
16-bit integers, representing the x, y, and z coordinates of each point.
The z coordinates are always zero.

TWE - Tween Data Files

A TWE file holds information about a tweening operation set up via the
Tween menus. The information includes the starting and ending shapes, and
the optional userD specified links between the shapes. Animator Pro creates
tween files.

A TWE file begins with an 8-byte header defined as follows:

Offset  Length  Name         Description

  0       2     magic        File format identifier. Always hex 1995.

  2       2     version      The file format version; always zero.

  4       4     tcount       The number of tween shapes in the file;
                             always 2.

  8       8     reserved     Unused space; set to zeroes.

  16      4     linkcount    The number of link entries in the file.

Immediately following the file header are the link entries. If the
linkcount value is zero there are no links. Each link entry is a pair of
32-bit integers. The first value in each pair is the index of the point in
the first shape, and the second value is the index of the point in the
ending shape. (IE, a link value of 2,7 says to link the second
starting-shape point to the seventh ending-shape point.)

Following the link entries is the data block that describes the starting
shape, then the data block that describes the ending shape. The format of
these blocks is identical to that of the polygon (PLY) file, including file
header data. In other words, they appear as if a pair of polygon files are
embedded in the tween file at this point.

OPT - Optics Menu Settings Files

An OPT file holds information about an optics operation set up via the
Optics menus. Both Animator Pro and the original Animator create OPT files.
The file format is the same for both.

An OPT file starts with a 4-byte header, as follows:

Offset  Length  Name         Description

  0       2     magic        File type identifier.  Always hex 1A3F.

  2       2     count        Number of records in the file.

Following the file header are optics records of 50 bytes each. A record is
generated for each click on CONTINUE MOVE in the OPTICS menu. The move
records are formatted as follows:

Offset  Length  Name         Description

  0       4     link         In the file, this field is always zero.
                             In memory, it's a pointer to the next
                             move record.

  4       6     spincenter   The x,y,z coordinates of the spin
                             center point; three 16-bit values.

  10      6     spinaxis     The x,y,z coordinates of the spin axis;
                             three 16-bit values.

  16      6     spinturns    The x,y,z coordinates of the spin turns;
                             three 16-bit values.

  22      4     spininter    Intermediate turns.  Two 16-bit values.
                             These are values for a conjugation matrix
                             that corresponds to spin axis.

  26      6     sizecenter   The x,y,z coordinates of the size
                             center point; three 16-bit values.

  32      2     xmultiplier  Determines (along with xdivisor)
                             how to scale along x dimension.

  34      2     xdivisor     Determines (along with xmultiplier) how
                             to scale along x dimension.

  36      2     ymultiplier  Determines (along with ydivisor)
                             how to scale along y dimension.

  38      2     ydivisor     Determines (along with ymultiplier) how
                             to scale along y dimension.

  40      2     bothmult     Like xmultiplier, but applied to both
                             dimensions.

  42      2     bothdiv      Like xdivisor, but applied to both
                             dimensions.

  44      6     linearmove   The x,y,z offset for a linear move;
                             three 16-bit values.

Internal Usage Files (REC, SET, CFG, GLV, MU)

Each of these file types is created by Animator Pro to store internal data
between sessions. These files must not be touched by other applications.

REC files store macros. Animator Pro REC files are not the same as the REC
files documented with the original Animator.

SET files store internal settings information; they are created by the
Quit-Save menu, and by the Save Default Settings menu.

CFG files store internal configuration information, such as the video
driver and mode.

GLV files store Poco Global Variables. The data is stored as a series of
nullterminated strings, and must not be modified using a normal text
editor.

MU files store menu text, prompts, error messages, etc, customized to the
proper native language. The data is stored as normal ASCII text, and must
not be modified in any way.

End of document.

Below are a few comments that hold text we may want to suck back into the
document some day. When the prefix chunk is present, it contains a fixed
header structure, followed by one or more prefix sub-chunks. The prefix
chunk header is defined as follows:

The following constants identify the sub-chunks within a prefix chunk.

     enum {
          FP_FREE        = 0,
          FP_FLIPATH          = 1,
          FP_VSETTINGS   = 2,
          FP_CELDATA          = 3,
          };

Format for the optional Prefix chunk:

The prefix chunk at present contains:

A settings chunk. This is the same thing as a settings file but as a chunk
in a flic. This is how the load settings from a flic is implemented. This
is present in flics but not cels. A settings chunk has sub chunks for
things like the paths in the file requestors, optics settings, etc.

A Celdata chunk. This chunk has the positioning info for a fli used as a
cel. This is usually only present in cel files.

                                [icon bar]
                   MédiaTel | Map | Search | Contact Us
