Subversion Repositories Kolibri OS

idea behind it is simple: don't bother storing the parts of a

frame that are the same as the last frame.  Not only does this

save space, but it's very quick.  It's faster to leave a pixel

alone than to set it.

frames. The first frame is compressed using a bytewise run-length

compression scheme.  Subsequent frames are stored as the

difference from the previous frame.  (Occasionally the first

frame and/or subsequent frames are uncompressed.)  There is one

extra frame at the end of a FLI which contains the difference

between the last frame and the first frame.

     offset

     4    2    magic     Set to hex AF11.  Please use another

                         value here if you change format (even to

                         a different resolution) so Autodesk

                         Animator won't crash trying to read it.

     6    2    frames    Number of frames in FLI.  FLI files have

                         a maxium length of 4000 frames.

     8    2    width     Screen width (320).

     10   2    height    Screen height (200).

     12   2    depth     Depth of a pixel (8).

     14   4    flags     Must be 0.

     18   2    speed     Number of video ticks between frames.

     20   4    next      Set to 0.

     24   4    frit      Set to 0.

     28   100  expand    All zeroes -- for future enhancement.

     offset

     0    4    size      Bytes in this frame.  Autodesk Animator

     4    2    magic     Always hexadecimal F1FA

     6    2    chunks    Number of 'chunks' in frame.

     8    8    expand    Space for future enhancements.  All

                         zeros.

frame.  First comes a color chunk if the color map has changed

from the last frame.  Then comes a pixel chunk if the pixels have

changed.  If the frame is absolutely identical to the last frame

there will be no chunks at all.

chunk header is:

     offset

     0    4    size Bytes in this chunk.

file.

     11        FLI_COLOR Compressed color map

     12        FLI_LC    Line compressed -- the most common type

                         of compression for any but the first

                         frame.  Describes the pixel difference

                         from the previous frame.

     13        FLI_BLACK Set whole screen to color 0 (only occurs

                         on the first frame).

     15        FLI_BRUN  Bytewise run-length compression -- first

                         frame only

     16        FLI_COPY  Indicates uncompressed 64000 bytes soon

                         to follow.  For those times when

                         compression just doesn't work!

compressed data ends up being an odd length a single pad byte is

inserted so that the FLI_COPY's always start at an even address

for faster DMA.

     The first word is the number of packets in this chunk. This

is followed directly by the packets.  The first byte of a packet

says how many colors to skip.  The next byte says how many colors

to change.  If this byte is zero it is interpreted to mean 256.

Next follows 3 bytes for each color to change (one each for red,

green and blue).

     This is the most common, and alas, most complex chunk.   The

first word (16 bits) is the number of lines starting from the top

of the screen that are the same as the previous frame. (For

example, if there is motion only on the bottom line of screen

you'd have a 199 here.)  The next word is the number of lines

that do change.  Next there is the data for the changing lines

themselves.  Each line is compressed individually; among other

things this makes it much easier to play back the FLI at a

reduced size.

in this line.  If the line is unchanged from the last frame this

is zero.  The format of an individual packet is:

size_count

data

are to be skipped it must be broken into 2 packets. The size

count is also a byte.  If it is positive, that many bytes of data

follow and are to be copied to the screen.  If it's negative a

single byte follows, and is repeated -size_count times.

comes out to be 60000 bytes or more Autodesk Animator decides

compression isn't worthwhile and saves the frame as FLI_COPY.

     These are very simple.  There is no data associated with

them at all. In fact they are only generated for the first frame

in Autodesk Animator after the user selects NEW under the FLIC

menu.

     These are much like FLI_LC chunks without the skips.  They

start immediately with the data for the first line, and go line-

by-line from there.  The first byte contains the number of

packets in that line.  The format for a packet is:

data

which is repeated size_count times. If size_count is negative

there are -size_count bytes of data which are copied to the

screen. In Autodesk Animator if the "compressed" data shows signs

of exceeding 60000 bytes the frame is stored as FLI_COPY instead.

     These are 64000 bytes of data for direct reading onto the

screen.

And here's the PRO extensions:

-----------------------------------------------------------------------

that are not described in the Turbo C FLI library documentation.

  ----------       -----------

  FLI_DELTA        7 (decimal)

  is the data for the changing lines themselves, always starting with the

  first line.   Each line is compressed individually.

  the line.  If the number of packets is a negative skip -packets lines.

  If the number of packets is positive, decode the packets.  The format of

  an individual packet is:

  size_count

  data

  skipped, it must be broken into 2 packets.  The size_count is also a byte.

  If it is positive, that many WORDS of data follow and are to be copied to

  the screen.  If it is negative, a single WORDS value follows, and is to be

  repeated -size_count times.

  ----------       -----------

  FLI_256_COLOR    4 (decimal)

  directly by the packets.  The first byte of a packet is how many colors

  to skip.  The next byte is how many colors to change.  If this number is

  0, (zero), it means 256.  Next follow 3 bytes for each color to change.

  (One each for red, green and blue).

  FLI_COLOR chunk (type 11 decimal) is that the values in the type 4 chunk

  range from 0 to 255, and the values in a type 11 chunk range from 0 to 63.

         WORDS refer to two-bytes (16 bits) of consecutive data. (Big Endian)

  ----------       -----------

  FLI_MINI         18 (decimal) 12 (Hex)

  frame in FLI_BRUN format, used as an button for selecting flc's from

  within Animator Pro.  Simply do nothing with this chunk.

  is the first frame in the .flc file.  Actually it isn't a frame at all

  but to have several chunks within it that specify file location info

  specific to Animator Pro.  IE:  filepath, font to use, and .COL file info.

  This FRAME may be skipped while loading.  That's right!  Ignore it!  The

  frame header is the same length as all other frames.  So you may read the

  frame header, then skip past the rest of the frame.

  FLI signature bytes are AF12 instead of AF11 used in the older FLI files.

  Also, you cannot ignore the screen width and height they may not be

  320 x 200.

  second instead of 70th's.

please let me know.

(corrected by P. Oliver 30 May 1997 using information supplied by Reeves Hall)

Delphi     : MikeHaaland

Internet   : mike@htsmm1.las-vegas.nv.us

Usenet     : ...!htsmm1.las-vegas.nv.us!mike