16/PCGPE10/FLI.FOR

   1 \r
   2  \r
   3 Flic Files (.FLI) Format description:\r
   4  \r
   5      The details of a FLI file are moderately complex, but the\r
   6 idea behind it is simple: don't bother storing the parts of a\r
   7 frame that are the same as the last frame.  Not only does this\r
   8 save space, but it's very quick.  It's faster to leave a pixel\r
   9 alone than to set it.\r
  10  \r
  11      A FLI file has a 128-byte header followed by a sequence of\r
  12 frames. The first frame is compressed using a bytewise run-length\r
  13 compression scheme.  Subsequent frames are stored as the\r
  14 difference from the previous frame.  (Occasionally the first\r
  15 frame and/or subsequent frames are uncompressed.)  There is one\r
  16 extra frame at the end of a FLI which contains the difference\r
  17 between the last frame and the first frame.\r
  18  \r
  19      The FLI header:\r
  20  \r
  21      byte size name      meaning\r
  22      offset\r
  23  \r
  24      0    4    size      Length of file, for programs that want\r
  25                          to read the FLI all at once if possible.\r
  26      4    2    magic     Set to hex AF11.  Please use another\r
  27                          value here if you change format (even to\r
  28                          a different resolution) so Autodesk\r
  29                          Animator won't crash trying to read it.\r
  30      6    2    frames    Number of frames in FLI.  FLI files have\r
  31                          a maxium length of 4000 frames.\r
  32      8    2    width     Screen width (320).\r
  33      10   2    height    Screen height (200).\r
  34      12   2    depth     Depth of a pixel (8).\r
  35      14   2    flags     Must be 0.\r
  36      16   2    speed     Number of video ticks between frames.\r
  37      18   4    next      Set to 0.\r
  38      22   4    frit      Set to 0.\r
  39      26   102  expand    All zeroes -- for future enhancement.\r
  40  \r
  41      Next are the frames, each of which has a header:\r
  42  \r
  43      byte size name      meaning\r
  44      offset\r
  45      0    4    size      Bytes in this frame.  Autodesk Animator\r
  46                          demands that this be less than 64K.\r
  47      4    2    magic     Always hexadecimal F1FA\r
  48      6    2    chunks    Number of 'chunks' in frame.\r
  49      8    8    expand    Space for future enhancements.  All\r
  50                          zeros.\r
  51  \r
  52      After the frame header come the chunks that make up the\r
  53 frame.  First comes a color chunk if the color map has changed\r
  54 from the last frame.  Then comes a pixel chunk if the pixels have\r
  55 changed.  If the frame is absolutely identical to the last frame\r
  56 there will be no chunks at all.\r
  57  \r
  58      A chunk itself has a header, followed by the data.  The\r
  59 chunk header is:\r
  60  \r
  61      byte size name meaning\r
  62      offset\r
  63      0    4    size Bytes in this chunk.\r
  64      4    2    type Type of chunk (see below).\r
  65  \r
  66      There are currently five types of chunks you'll see in a FLI\r
  67 file.\r
  68  \r
  69      number    name      meaning\r
  70      11        FLI_COLOR Compressed color map\r
  71      12        FLI_LC    Line compressed -- the most common type\r
  72                          of compression for any but the first\r
  73                          frame.  Describes the pixel difference\r
  74                          from the previous frame.\r
  75      13        FLI_BLACK Set whole screen to color 0 (only occurs\r
  76                          on the first frame).\r
  77      15        FLI_BRUN  Bytewise run-length compression -- first\r
  78                          frame only\r
  79      16        FLI_COPY  Indicates uncompressed 64000 bytes soon\r
  80                          to follow.  For those times when\r
  81                          compression just doesn't work!\r
  82  \r
  83      The compression schemes are all byte-oriented.  If the\r
  84 compressed data ends up being an odd length a single pad byte is\r
  85 inserted so that the FLI_COPY's always start at an even address\r
  86 for faster DMA.\r
  87  \r
  88 FLI_COLOR Chunks\r
  89      The first word is the number of packets in this chunk. This\r
  90 is followed directly by the packets.  The first byte of a packet\r
  91 says how many colors to skip.  The next byte says how many colors\r
  92 to change.  If this byte is zero it is interpreted to mean 256. \r
  93 Next follows 3 bytes for each color to change (one each for red,\r
  94 green and blue).\r
  95  \r
  96 FLI_LC Chunks\r
  97      This is the most common, and alas, most complex chunk.   The\r
  98 first word (16 bits) is the number of lines starting from the top\r
  99 of the screen that are the same as the previous frame. (For\r
 100 example, if there is motion only on the bottom line of screen\r
 101 you'd have a 199 here.)  The next word is the number of lines\r
 102 that do change.  Next there is the data for the changing lines\r
 103 themselves.  Each line is compressed individually; among other\r
 104 things this makes it much easier to play back the FLI at a\r
 105 reduced size.\r
 106  \r
 107      The first byte of a compressed line is the number of packets\r
 108 in this line.  If the line is unchanged from the last frame this \r
 109 is zero.  The format of an individual packet is:\r
 110  \r
 111 skip_count\r
 112 size_count\r
 113 data\r
 114  \r
 115      The skip count is a single byte.  If more than 255 pixels\r
 116 are to be skipped it must be broken into 2 packets. The size\r
 117 count is also a byte.  If it is positive, that many bytes of data\r
 118 follow and are to be copied to the screen.  If it's negative a\r
 119 single byte follows, and is repeated -skip_count times.\r
 120  \r
 121      In the worst case a FLI_LC frame can be about 70K.  If it\r
 122 comes out to be 60000 bytes or more Autodesk Animator decides\r
 123 compression isn't worthwhile and saves the frame as FLI_COPY.\r
 124  \r
 125 FLI_BLACK Chunks\r
 126      These are very simple.  There is no data associated with\r
 127 them at all. In fact they are only generated for the first frame\r
 128 in Autodesk Animator after the user selects NEW under the FLIC\r
 129 menu.\r
 130  \r
 131 FLI_BRUN Chunks\r
 132      These are much like FLI_LC chunks without the skips.  They\r
 133 start immediately with the data for the first line, and go line-\r
 134 by-line from there.  The first byte contains the number of\r
 135 packets in that line.  The format for a packet is:\r
 136 \r
 137 size_count\r
 138 data\r
 139  \r
 140      If size_count is positive the data consists of a single byte\r
 141 which is repeated size_count times. If size_count is negative\r
 142 there are -size_count bytes of data which are copied to the\r
 143 screen. In Autodesk Animator if the "compressed" data shows signs\r
 144 of exceeding 60000 bytes the frame is stored as FLI_COPY instead.\r
 145  \r
 146 FLI_COPY Chunks\r
 147      These are 64000 bytes of data for direct reading onto the\r
 148 screen.\r
 149  \r
 150 -----------------------------------------------------------------------\r
 151 And here's the PRO extensions:\r
 152 -----------------------------------------------------------------------\r
 153  \r
 154 This is supplemental info on the AutoDesk Animator FLI and FLC formats.\r
 155  \r
 156 The following is an attempt at describing the newer chunks and frames\r
 157 that are not described in the Turbo C FLI library documentation.\r
 158  \r
 159   Chunk type       Chunk ID \r
 160   ----------       -----------\r
 161   FLI_DELTA        7 (decimal)\r
 162   \r
 163   First WORD (16 bits) is the number of compressed lines to follow.  Next\r
 164   is the data for the changing lines themselves, always starting with the\r
 165   first line.   Each line is compressed individually.\r
 166  \r
 167   The first WORD (16 bits) of a compressed line is the number of packets in\r
 168   the line.  If the number of packets is a negative skip -packets lines.\r
 169   If the number of packets is positive, decode the packets.  The format of\r
 170   an individual packet is:\r
 171  \r
 172   skip_count\r
 173   size_count\r
 174   data\r
 175  \r
 176   The skip count is a single byte.  If more than 255 pixels are to be\r
 177   skipped, it must be broken into 2 packets.  The size_count is also a byte.\r
 178   If it is positive, that many WORDS of data follow and are to be copied to\r
 179   the screen.  If it is negative, a single WORDS value follows, and is to be\r
 180   repeated -size_count times.\r
 181 \r
 182   Chunk type       Chunk ID \r
 183   ----------       -----------\r
 184   FLI_256_COLOR    4 (decimal)\r
 185  \r
 186   The first WORD is the number of packets in this chunk.  This is followed\r
 187   directly by the packets.  The first byte of a packet is how many colors\r
 188   to skip.  The next byte is how many colors to change.  If this number is\r
 189   0, (zero), it means 256.  Next follow 3 bytes for each color to change.\r
 190   (One each for red, green and blue).\r
 191  \r
 192   The only difference between a FLI_256_COLOR chunk (type 4 decimal) and a\r
 193   FLI_COLOR chunk (type 11 decimal) is that the values in the type 4 chunk\r
 194   range from 0 to 255, and the values in a type 11 chunk range from 0 to 63.\r
 195  \r
 196   NOTE:  WORD  refer to a 16 bit int in INTEL (Little Endian) format.\r
 197          WORDS refer to two-bytes (16 bits) of consecutive data. (Big Endian)\r
 198  \r
 199   .FLC special frames and chunks\r
 200  \r
 201   FLC's may contain all the above chunks plus one other:\r
 202  \r
 203   Chunk type       Chunk ID \r
 204   ----------       -----------\r
 205   FLI_MINI         18 (decimal) 12 (Hex)\r
 206  \r
 207   From what I understand,  this is a miniture 64 x 32 version of the first\r
 208   frame in FLI_BRUN format, used as an button for selecting flc's from\r
 209   within Animator Pro.  Simply do nothing with this chunk.\r
 210  \r
 211   FLC New Frame\r
 212  \r
 213   FLC's also contains a frame with the magic bytes set to hex 00A1.  This\r
 214   is the first frame in the .flc file.  Actually it isn't a frame at all\r
 215   but to have several chunks within it that specify file location info\r
 216   specific to Animator Pro.  IE:  filepath, font to use, and .COL file info.\r
 217   This FRAME may be skipped while loading.  That's right!  Ignore it!  The\r
 218   frame header is the same length as all other frames.  So you may read the\r
 219   frame header, then skip past the rest of the frame.\r
 220  \r
 221  \r
 222   NOTE:  When reading the FLI header on the newer FLI and FLC files, the\r
 223   FLI signature bytes are AF12 instead of AF11 used in the older FLI files.\r
 224   Also, you cannot ignore the screen width and height they may not be\r
 225   320 x 200.\r
 226 \r
 227   Allowable screen sizes include:\r
 228  \r
 229   320 x 200, 640 x 480, 800 x 600, 1280 x 1024\r
 230  \r
 231  \r
 232   NOTE:  the delay value between frames appears to be in 1000th's of a\r
 233   second instead of 70th's.\r
 234  \r
 235 If you have any questions or more info on the FLI or FLC formats,\r
 236 please let me know.\r
 237  \r
 238 Mike Haaland\r
 239  \r
 240 CompuServe : 72300,1433\r
 241 Delphi     : MikeHaaland\r
 242 Internet   : mike@htsmm1.las-vegas.nv.us\r
 243 Usenet     : ...!htsmm1.las-vegas.nv.us!mike\r
 244  \r