This is xflick, the .FLI animation displayer. See the top of xflick.c for public domain information. BUGS ---- There seem to be some glitches on raytraced and "drawn" FLIs that I have seen. I haven't been able to figure out why. There may be some special situations which are not described in the FLI document below, which is the only one I have. Limitations ----------- It only works for 320x200, but that is the only size supported by the type anyway. There is no scaling yet. SPECIAL THANKS -------------- Special thanks go to Kevin Darling (kdarling@hobbes.ncsu.edu) for supplying us with the .fli format information, and much help during development. Special thanks also go to Brad Daniels (daniels@bigred.enet.dec.com) for helping with X stuff and general animation stuff. I also copied the public domain header at the top of xflick.c mostly from his xviewgl (I wonder if this violates anything!). Installation ------------ Type 'make'. Usage ----- xflick [-r] filename where repeat_count is the number of times to repeat the loop, default 10. FLI FORMAT ---------- >From: kdarling@hobbes.ncsu.edu (Kevin Darling) 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 less 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 his 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 skipf 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