178 lines
7.1 KiB
Plaintext
178 lines
7.1 KiB
Plaintext
|
||
From: kdarling@hobbes.ncsu.edu (Kevin Darling)
|
||
Newsgroups: comp.graphics
|
||
Subject: Re: FLI file-format?
|
||
Message-ID: <1991Mar12.202026.5005@ncsu.edu>
|
||
Date: 12 Mar 91 20:20:26 GMT
|
||
Organization: North Carolina State University
|
||
|
||
>Has someone a description of the FLI-format?
|
||
|
||
Autodesk Animator files explanation (.FLI only excerpted). I believe
|
||
that the original programmer wrote up this doc. It's correct, as I've
|
||
used the info to realtime playback stock .FLIs on a 680x0 machine.
|
||
All numbers in a .FLI file are in Intel format, so you may have to
|
||
compensate for that, of course. - kevin
|
||
|
||
8.1 Flic Files (.FLI)
|
||
|
||
The details of a FLI file are moderately complex, but the
|
||
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.
|
||
|
||
A FLI file has a 128-byte header followed by a sequence of
|
||
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.
|
||
|
||
The FLI header:
|
||
|
||
byte size name meaning
|
||
offset
|
||
|
||
0 4 size Length of file, for programs that want
|
||
to read the FLI all at once if possible.
|
||
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
|
||
14 2 flags Must be 0.
|
||
16 2 speed Number of video ticks between frames.
|
||
18 4 next Set to 0.
|
||
22 4 frit Set to 0.
|
||
26 102 expand All zeroes -- for future enhancement.
|
||
|
||
Next are the frames, each of which has a header:
|
||
|
||
byte size name meaning
|
||
offset
|
||
0 4 size Bytes in this frame. Autodesk Animator
|
||
demands that this be less than 64K.
|
||
4 2 magic Always hexadecimal F1FA
|
||
6 2 chunks Number of 'chunks' in frame.
|
||
8 8 expand Space for future enhancements. All zeros.
|
||
|
||
After the frame header come the chunks that make up the
|
||
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.
|
||
|
||
A chunk itself has a header, followed by the data. The
|
||
chunk header is:
|
||
|
||
byte size name meaning
|
||
offset
|
||
0 4 size Bytes in this chunk.
|
||
4 2 type Type of chunk (see below).
|
||
|
||
There are currently five types of chunks you'll see in a FLI
|
||
file:
|
||
|
||
number name meaning
|
||
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!
|
||
|
||
The compression schemes are all byte-oriented. If the
|
||
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.
|
||
|
||
FLI_COLOR Chunks
|
||
|
||
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).
|
||
|
||
FLI_LC Chunks
|
||
|
||
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.
|
||
|
||
The first byte of a compressed line is the number of packets
|
||
in this line. If the line is unchanged from the last frame this
|
||
is zero. The format of an individual packet is:
|
||
|
||
skip_count
|
||
size_count
|
||
data
|
||
|
||
The skip count is a single byte. If more than 255 pixels
|
||
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 -skip_count times.
|
||
|
||
In the worst case a FLI_LC frame can be about 70K. If it
|
||
comes out to be 60000 bytes or more Autodesk Animator decides
|
||
compression isn't worthwhile and saves the frame as FLI_COPY.
|
||
|
||
FLI_BLACK Chunks
|
||
|
||
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.
|
||
|
||
FLI_BRUN Chunks
|
||
|
||
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:
|
||
|
||
size_count
|
||
data
|
||
|
||
If size_count is positive the data consists of a single byte
|
||
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.
|
||
|
||
FLI_COPY Chunks
|
||
|
||
These are 64000 bytes of data for direct reading onto the
|
||
screen.
|
||
|
||
-eof-
|
||
|
||
Notes: Since these are animations, the last frame will delta into a
|
||
copy of the first one (which was usually a large BRUN chunk). Therefore,
|
||
looping should go back to the _second_ frame chunk (usually a LC
|
||
or COLOR chunk) instead of all the way back to the file beginning, to
|
||
avoid a "stutter" caused by unnecessarily redecoding the original frame.
|
||
Also, a very few files may have palette animation, so write your code
|
||
so that COLOR chunks can be found at any time. - kevin
|
||
|
||
|
||
|