FIGlet uses flc file type for its internal purposes and/or also by different way than common edit or open file actions (eg. To install/execute/support an application itself, to store application or user data, configure program etc.). File Format:.flc. File Type: FLIC Animation. The FLC file is an animation file based off the FLC format. The FLC file contains a movie clip created by Autodesk animation software, such as Animator Pro. Images used in the animation are compressed with RLE compression to reduce file size. Created by: Autodesk, Inc. Click on icon and select the Add File Type tab from the Settings window. Click the Add button to browse to the location of the file type you want to add. You need to add at least 10 or more samples/files of the same type to include it in the list of supported file types. The name of the added file type will be listed in the left.
In this paper, you will find the file format specifications for a class ofanimation files that fall in the 'FLIC' file category. These include:| FLI files (Autodesk Animator) | FLC files (Autodesk Animator Pro) |
| FLH & FLT files (DTA) | CEL files (Autodesk Animator) |
| FLX files (Tempra Pro, Mathematica Inc.) | FLX files (U-Lead, 3DStudio MAX) |
| Extensions by Pro Motion (Cosmigo) | Extensions by EGI (CompuPhase) |
The original FLIC file format was described by its author (Jim Kent) inDr. Dobb's Journal, March 1993. The original purpose ofthis document was to document the modifications and extensions thatEGI (a FLIC compiler and player engine) adds tothe FLIC file format, but since then it has grown to include all otherextensions and variations as well. As you may not have Jim Kent's article, allstandard file information is included in this paper as well.
- Standing for Flash Video, a file with the.FLV file extension is a file that uses Adobe Flash Player or Adobe Air to transmit video or audio over the internet. Flash Video has long been the standard video format used by nearly all embedded video on the internet including the videos found on YouTube, Hulu, and many more websites.
- Save as a different file name, type, or download location on your PC. Run the app, extension, or other file type. After Internet Explorer runs a security scan, the file will open and run on your PC. Cancel the download and go back to browsing the web. You can also save smaller files—like single pictures—to your PC.
There are two 'official' types of FLIC files: FLIand FLC (the names of these types refer to the filename extensions). The FLIfiles are the older format and are limited to a resolution of 320×200.The FLC file format adds configurable resolution and better compression.
FLX files are a slight variation on the standard FLC format. Actually, thereare two FLX file formats with slight differences. Both formats use32768 colours in a packed RGB format (15-bpp, each pixel takes two bytes).The first FLX format was defined for 'Tempra Pro' by Mathematica Inc. Theformat used by 3DStudio MAX (Discreet Inc.) also has the extension FLX buttheir format is more like that of 15-bpp FLH files. Where distinction is needed,this paper refers to 'Tempra FLX' or to 'Autodesk FLX' formats (Discreet isaffiliated to Autodesk).
Download os x yosemite to usb. Both 'Tempra FLX' and 'Autodesk FLX' formats use the RLE compression thatwas originally designed for 8-bpp FLC files, which is a sub-optimal solution.To improve the compression and to make the file format more flexible withregard to colour depth, Dave K. Mason defined new chunk types for his DTAprogram, in addition to tagging the new format with a new 'type' ID and newextensions (FLH and FLT) as to avoid confusion. A few other programs, notablyEGI, also support the DTA chunks and type IDs.
CEL files, finally, are actually either FLI or FLC files with a differentextension and one more chunk in the 'prefix data' (a kind of optional header).
Overview
A FLIC file stores a number of frames. Every frame contains an image andpossibly a palette, a label, or other data. Usually, a FLIC file contains aring frame at the end, so that the animation can be played repeatedly withouta perceptible pause between the last frame and the first (the unpacking of thefirst frame, a complete image, is generally slower than a delta frame update).A FLIC file that contains segments (EGI extension) optionally contains a ringframe per segment.
FLIC files are structured in a hierarchy of chunks. A chunk contains afixed part and a variable part. The fixed part of every chunk contains thetype and the size of the chunk. The rest of the chunk has no fixed format; itall depends on the chunk type. The purpose of the chunked structure is toallow new chunks to be added without breaking existing FLIC players. A readerthat does not understand some chunk type can just skip it (using theinformation from the fixed part of the chunk). The figure below shows thehierarchy of chunks in a FLIC file.
All 'word' (two bytes) or 'double word' (four bytes) values are stored inLittle Endian (this is the byte order used by the Intel 80x86 and Pentiumprocessor series).
The file header
A FLIC file starts with a 128-byte header, seethe figure below for a C structure. Thetype field contains:| 0xAF11 | For FLI files |
| 0xAF12 | For standard FLC files (with an8-bit colour depth). FLX files (both 'Tempra FLX' and 'Autodesk FLX') alsouse this header type. |
| 0xAF44 | For FLIC files witha colour depth other than 8. The DTA program (by Dave K. Mason) makesFLIC files with a colour depth of 1, 15, 16 or 24 bits per pixel.EGI version 3.0 (and later) supports 16-bpp FLIC files. |
| 0xAF30 | For FLIC files thatuse Huffman or BWT compression. These FLIC files can also havea colour resolution that is different from 8 bits per pixel. |
| 0xAF31 | For FLIC files thatuse 'frame shift' compression. These FLIC files may use additional compressionschemes like Huffman and BWT; They can also have a colour resolution that isdifferent from 8 bits per pixel. |
| ??? | Password protected FLIC files have ascrambled type field, so that previous versions of EGI and otherFLIC readers will identify them as invalid (or unknown)FLIC files. |
For FLI files, the delay between two frames is in increments of1/70 second; FLC files specify the speed in milliseconds.The header for a FLI file does not contain the offset of thefirst and second frames; the first frame is assumed to start directly behindthe file header (no 'prefix', 'segment table' or 'Huffman table' chunks) andthe offset to the second frame is easily computed once you read in the headerof the first frame. The purpose of storing the offset to the second frame isthat, after playing the ring frame, the next frame to display is thesecond frame of the animation.
Autodesk Animator Pro also stores the MS-DOS formatted date and time stampsof the initial creation and last update of the FLIC file, as wellas the serial number of the copy of the Animator Pro program that made/updatedthe file (in the creator and updater fields). Otherutilities set the creator field to:| 0 | Unknown (Pro Motion, DTA, VFD or other) |
| 0x45474900 | EGI |
| 0x464c4942 | FlicLib |
| 0x42494c46 | FlicLib - release 2 |
| 0x41544542 | Micrografx Simply3D |
| 0x30314c46 | Discreet 3DStudio MAX |
The frames field in the FLIC file header does notinclude the ring frame that loops back to the beginning of the animation.
The flags field is used internally by Autodesk Animator Pro. If aFLIC file is written to disk and closed correctly, Animator Prosets this field to 3. Several other utilities set it to zero.
What Is Flc File
The modifications that EGI made to the FLIC file header are subtler.Not only are there a few added fields, but you must also decide whether thefields are valid:
- First verify that the FLIC file is created by EGI. If the 'creator' fieldof the FLIC file header is not equal to 0x45474900, the ext_flagsfield is not valid.
- The ext_flags field indicates what extensions were used. If this value iszero (no extensions) the file is a 'compatible' FLC file.
bit meaning 0 file contains segments (segment table present) 1 file contains key images at regular intervals 2 all frames have an identity palette 3 file is Huffman compressed 4 file is BWT-Huffman compressed 5 bitmap masks are present 6 multilevel masks are present 7 region data is present 8 file is password protected 9 animation file contains digitized audio 10 animation file contains a script 11 region masks are present 12 animation file contains overlays 13 file is frame-shift compressed - If the script contains 'segment' instructions, the EGI compiler produces a segmenttable. The segment table will come right after the FLIC header. Bit 0 of the'ext_flags' field indicates whether there is a segment table in the file.
- In a segmented file, the 'frames' field is set to the number of framesin the first segment (excluding the optional ring frame). Likewise, thefields for the offsets to the first and second frames ('oframe1' and'oframe2') are set to those of the first segment.
- The totalframes field is the total number of frames in all segments,including all ring frames.
Chunks and subchunks
Every chunk starts with a 6-byte header, that contains the size (fourbytes) and the type (two bytes) for the chunk. All chunks sizes should berounded up to an even number of bytes. The values of the main levelchunks are above 0xF100, values of the subchunks are below 100(decimal). As you can see in figure 'Overview of the FLIC file structure',nearly all of the subchunks appear in the 'frame' chunk.
Chunks types are indicated in the FLIC file with a two-bytevalue, but Jim Kent's article tagged names on those values (these names appearto be extracted from the Animator Pro source code). For ease of writing, I usethe same names, in the same glorious ALL UPPER CAPS' that hasbecome common in discussing the FLIC file format.
The rest of the document discusses these chunks and subchunks in detail.On the right of the caption for each chunk type is the product for whichthis chunk is valid. Autodesk Animator is not mentioned explicitly, becausethere exist (to my knowledge) no chunks that only Animatorsupports.
The CEL_DATA chunk is usually not present in FLCfiles. Intermediate files used by Autodesk Animator Pro with the.CEL extension usually contain a CEL_DATA in theprefix chunk. The CEL files have the same format asFLC files.
EGI version 3.0 and later may generate CEL_DATA chunks inside normalframes; i.e. outside the prefix chunk. EGI uses the CEL_DATA chunkto hold the origin of the frame. Sprite animation toolkits can use the originof a frame for run-time 'registration' of the frame. (Registration is a termthat animators use to mean the correct positioning of a frame in relation tothe other frames and to the background image.)
EGI uses only the center_x and center_y fieldsof the structure. The center_x field gives the horizontal offsetof the origin relative to the left edge of the frame. The center_yfield is the vertical offset of the origin relative to the top edge, where apositive value points downwards.
In EGI 4.0, the overlay array holds up to 16 labels of overlays that canapply to a frame. When an element in this array is zero, this means 'no overlay'.The FLIC player chooses one of these overlays (or none) as thedefault overlay. Which overlay it chooses depends on the 'overlay index' thatone selects in the player. If the overlay index is zero, no overlay is displayed;if it is 1, the first overlay listed in the array is used, and so on.
EGI supports embedded run-time scripts in FLIC files that arewritten in the 'pawn' language.The compiled P-code is added to the FLIC file. The format of the compiled P-code and aninstruction reference can be found in the Small manual (available on-line asa PDF document on the Small language page mentioned earlier).
Specific functions in the run-time script execute on 'events' in theFLIC animation, such as reaching the last frame of the segment(this is the frame before the ring frame). The currently defined event functionsare:| Function | Description |
| @FlicClose() | Called when the animation is closed |
| @FlicFrame(framenumber) | Called after each frame is decoded |
| @FlicLabel(label) | Called when a label was reached |
| @FlicLastFrame() | Called when the animation reaches its last frame of the current segment |
| @FlicLButtonDown(x, y) | Called when the left mouse button is pressed in the animated frame |
| @FlicLButtonUp(x, y) | Called when the left mouse button is released in the animated frame |
| @FlicOpen() | Called when the animation is opened |
| @FlicPlay() | Called when the animation is starts playing |
| @FlicRButtonDown(x, y) | Called when the right mouse button is pressed in the animated frame |
| @FlicRButtonUp(x, y) | Called when the right mouse button is released in the animated frame |
| @FlicSegment(segmentnumber) | Called when a new segment has just started |
| @FlicStop() | Called when the animation is stopped explicitly |
If a segment table is present, it overrules the values in theheader (number of frames, offsets to the first andsecond frames).
The segment table contains a series of SEGMENT chunks, one forevery segment in the FLIC file. As of EGI version 4.0, the segment table alsostores LABELEX chunks that hold symbolic names for the segments. Thenumeric value of each LABELEX chunk must match the (numeric) label ofexactly one of the SEGMENT chunks. The name of the LABELEX chunkthen gives the symbolic name for the segment.
The flags field contains four bit flags:
If bit 1 is set, the first frame contains either a full image, or a deltaimage plus a key image. In other words, bit 1 indicates whether the segmentis a 'launch point'. See the EGI compiler instruction launch_pointfor more details.
The frames field does not include the ring frame (if a ringframe is present).
In a FLIC file has multiple segments and some of the segmentsare 'continued' from other segments (see the compiler instructioncontinued_from), a frame may contain both a full image (the keyimage) and a delta image. The EGI player uses the cont_image andlast_image fields to determine whether it can use the delta image(whose decoding is usually quicker than a full image), or whether it mustdecode the full image instead.
When creating the FLIC file, the EGI compiler assigns eachpicture a unique number. It stores the number of the last image in a segmentin the last_image field of the SEGMENT structure.When you add a continued_from instruction to the segment, thecompiler copies the last_image field of the segment that wasspecified in the continued_from instruction to thecont_image field of the current segment. The compiler thenproceeds to create a delta image given the first image of the current segmentand the last image of the 'continued from' segment. A segment that is notcontinued from another segment has a value of 0xFFFF in thecont_image field.
The EGI player goes the opposite route. Assuming that the player justdisplayed the last frame of a segment, and at that moment you switch toanother segment: if the last_image field of the current segmentis the same as the cont_image of the next field, the playerdecodes the delta image of the new segment. Otherwise it decodes the keyimage.
See the paper 'EGI compression schemes' forinformation on the Huffman compression algorithm. This chunk is only presentif bit 3 of the ext_flags of theFLIC file header is set.
El capitan install app. This chunk is defined by Autodesk Animator, but Pro Motion and EGI extend it.
The delay value overrules the speed field in theFLIC header; a value of zero indicatesthat the normal speed(from the FLIC header) applies. The delay field isan extension to the FLIC format, introduced byCosmigo's Pro Motion.
The frame size override (width and height) is an EGI extension (starting withEGI 4.0). It is currently only used for overlays.
The two subchunks with types 4 and 11 are identical, except that the rangeof the RGB values is 0-63 for COLOR_64 (type 11) and 0-255 forCOLOR_256 (type 4). The 0-63 range of COLOR_64 reflects the6-bit 'CLUT' hardware for the original VGA card (sometimes referred to as the18-bit DAC, where the 18-bits are divided into 3 channels).
The data in the chunk is organized in packets. The first word following thechunk header is the number of packets in the chunk. Each packet consists of a1-byte skip count, a 1-byte copy count and a series of 3-byte RGB values(the 'copy count' gives the number of RGB triplets). If the copy count iszero, there are 256 RGB triplets in the packet. For example, the data tochange colours 2, 7, 8 and 9 would appear as:
The FLIC file format assumes that when the palette changes, the entire frameis refreshed. Note that in a 256-colour FLIC file, pixel values arepalette-indices. When the colour definition of a palette entry changes, allpixels with the corresponding palette entry must take over the new colour,regardless of whether they are refreshed in a DELTA_FLIor a DELTA_FLC chunk. Note that if your video hardwareis physically in a palette mode (256-colours), this global colour refreshingis automatic. At the time that the FLIC format was developed, 256-colour palette-modevideo cards were state-of-the-art for desktop PCs.
All pixels in the frame have colour 0. This chunk has no data following thechunk header.
The data that follows the chunk header are the pixels of an uncompressedimage of the frame. The number of pixels are exactly width×heightof the frame. The first pixel is for the upper left corner of the frame.
Note that FLX files (15-bpp) use 2 bytes per pixel.
The data following the chunk header is a full image that is compressed withbyte oriented RLE. The first image of a segment and key frames are usuallystored in a BYTE_RUN chunk.
Each line of the image is compressed separately, starting from the top ofthe image. The first byte of each line is the packet count. It is a holdoverfrom the FLI format and it should be ignored, because it is nowpossible to have more than 255 packets on a line (for FLC files).Instead, the width of the frame image now is the criterion for decoding:continue decompressing until the number of uncompressed pixels becomes equalto the image width. However, some players still rely on this pack count, soFLIC compilers should still generate them and only set it to zerowhen the packet count indeed does exceed 255.
Each RLE packet consists of a count byte and one or more data bytes. If thecount byte is negative, its absolute value is the number of data bytes(following the count byte) to copy to the image: a literal run. If the countbyte is positive, the single data byte that follows must be replicated in theimage 'count' times: a replicate run.
This chunk is used for FLI type files; the newerFLC format replaces this chunk with DELTA_FLC (seebelow). The chunk contains the differences (the 'delta') between the currentframe and the previous frame.
The first 16-bit word behind the chunk header is the line number (startingfrom the top of the image) for the first line in the image that differs fromthe previous frame. In other words, it is a line skip count. The second wordis the number of lines in the chunk. The data for the lines themselves followthese two words.
Each line starts with a one-byte packet count for the line. Unlike theBYTE_RUN chunk, this value is significant because the 'delta'need not to store the complete width of the frame image. The packetsthemselves follow the packet count. Each packet consists of a column skipcount, an RLE count byte and zero or more data bytes. The column skip count isa one-byte value; it holdsthe number of pixels to skip (the number of pixels that did not change betweenthe current frame and the previous frame) from the current position in theline. It can have a value of zero. The RLE count byte and the data bytes aresimilar to the BYTE_RUN encoding: if the count is positive, thatnumber of bytes is to be copied from the data to the image (literal run); ifthe count is negative, its absolute value is the replication count of the onedata byte that follows (replicate run).
Two pitfalls:
This chunk is similar to the DELTA_FLI chunk, but itcompresses the delta image differently. The data following the chunk header isorganized into lines and each line is organized into packets. Every linestarts with one or more word-sized 'opcodes'.
The first word following the chunk header is the number of lines in thechunk. This count does not include 'skipped' lines. Each line starts with oneor more opcodes. One of the opcodes (the last) is the packet count. Thehighest two bits of the opcode word give its type:
The RLE compression of DELTA_FLC is similar to that ofDELTA_FLI, but it is word oriented. The first byte of each packetis the column skip count; the second byte is the RLE count byte. Zero or moredata words follow the RLE count byte. If the count is positive, thatnumber of words of data is copied to the image; if the count is negative, onedata word follows and the absolute value of the count tells how many timesthat word must be replicated in the image.
The two pitfalls from the DELTA_FLI chunk apply here too (seeabove). Additionally:
Flc File Type
A 'postage stamp' is a reduced image of the first frame of an animation. Apostage stamp created by Autodesk Animator Pro has the preferred size of100*63 (the actual size can vary) and uses a universal palette.
The palette is an RGB cube with 6 levels of each red, green and blue. Thistotals in 216 colours. An arbitrary RGB value (where each component is in therange of 0-255) is mapped into the six-cube space using:
The PSTAMP chunk embeds another chunk. This is usually aBYTE_RUN chunk or a FLI_COPY chunk (for compressedand uncompressed images respectively). If the type of the embedded chunk is 18again (the type of PSTAMP is also 18), that chunk contains a256-byte colour translation table. The translation table maps every paletteindex of the first frame to the universal six-cube colour space. To displaythe postage stamp, a program decodes the image of the first frame and mapsevery pixel of that image to the six-cube colour palette (using thetranslation table).
These chunks are generated by the DTA program by Dave K. Mason forFLIC files with 15-bit, 16-bit or 24-bit colour depth, and by EGIstarting with version 3.0. FLIC files with these formats usuallyhave a .FLH or a .FLT extension. EGI supports onlythe 16-bit variety of these chunks.
In 24-bit FLIC files, pixels are made up of three bytes in theorder B,G,R. In 16-bit files the colour values are packed into words (two-byteunits) in 'rrrrrggg gggbbbbb' format. 15-BitFLIC files have pixels packed into the format'0rrrrrgg gggbbbbb'. (The 'blue' bits are in the lowestbit positions of each word.)
The DTA_BRUN chunk is numbered 25 (instead of 15 for a standardBYTE_RUN). The Repeat/Copy value is still a byte, but it refers to anumber of pixels to copy or repeat, not bytes.
The DTA_LC chunk is numbered 27. Internally it is like chunktype 7 (DELTA_FLC). It starts with a number-of-lines value. Foreach line, the packet is a signed word value. If it is negative then itrepresents a lines-to-skip value and it does not count toward thenumber-of-lines. Each non-negative packet begins with a skip counter. This isstill a byte, but it represents a number of pixels to skip, not bytes. Nextcomes a repeat/copy packet. It represents a number of pixels to copy or skip,not words. (Though in a 16-bit FLIC file, the pixels are words.)
The copy chunk is numbered 26, although the standard 'copy' chunktype 16 (FLI_COPY) would do equally well: there is no decoding forcopy chunks.
The EGI API function FlicPlay() sends a notification message ifit encounters a label subchunk in a frame. The message is sent (usingeither the Microsoft Windows function SendMessage() or using a directcallback) after decoding (and displaying) the frame. If the FLIC file has anembedded script, a label invokes the public function@FlicLabel() in the script.
A bug in early versions of the EGI player caused it to assume that LABELchunks would always be exactly 10 bytes. Extending the label chunkwith additional could therefore cause compatibility problems with those earlyplayers. Macbook pro 2011 mojave patcher. Therefore, EGI defined a new, separate chunk for extended labels.
EGI versions as of version 4.0 store the symbolic name of a label (if any)in the chunk. The length of the name is the length of the chunk minus the fixedsize of the chunk and minus any padding. The fixed size of the chunk is 10bytes. The chunk is padded to an even size in bytes with zero bytes. So a labelname like 'eat' is stored as four characters 'e', 'a', 't' and '0'. A labelname like 'walk' is stored in four characters, the string is notzero-terminated.
For standard 256-colour FLIC files, the KEY_IMAGE chunk is thesame as BYTE_RUN, but a frame that has a KEY_IMAGEchunk also contains a DELTA_FLC from a previous segment. A playercan decide (based on the transition it makes from segment to segment) whetherto decode the KEY_IMAGE and skip the DELTA_FLC, orto decode the DELTA_FLC and skip the KEY_IMAGE. Seethe SEGMENT chunk for more information.
For 16-bit FLIC files, the KEY_IMAGE chunk has the sameencoding as DTA_BRUN. Similarly to the 256-colour FLIC files,the KEY_IMAGE chunk only appears in combination with aDTA_LC chunk.
The same as COLOR_256, but it is only present for key images.
The chunk MLEV_MASK is defined as of EGI version 2.0;the chunk BMP_MASK exists since EGI 1.0.
The chunk starts (right after the chunk header) with four 16-bit words thatgive the bounding box of the mask. You can use this bounding box to speed updrawing operations, because you do not have to draw anything outside this box(all pixels are transparent outside the bounding box). The values are storedin the following order: x y width height.
The mask data starts behind the bounding box. Each line is encodedseparately. A line starts with a 'line skip count', which indicates how manylines remain unchanged from the previous mask. It is a two-byte value. It iszero for every line in a full mask.
The bitmap data (for the mask bitmap) comes after the line skip count. Thebitmap data is compressed with the same RLE encoding as theBYTE_RUN image. This means that if the first (type) byte ispositive, it is followed by a single pixel that must be replicated; if it isnegative, it is followed by a series of bytes that must be copied literally.In contrast to the BYTE_RUN compression, no 'packet count' byteis stored at the beginning of a scan line. Each scan line of the mask iscompressed individually. Huffman and BWT compression do not apply to masks.
The data of a bitmap mask (after compression) is a 1 bit per pixel (8pixels per byte) bitmap with the same size as the frame image. Each bit thatis set ('1') represents a transparent pixel in the frame image. Each bit thatis cleared ('0') represents an opaque pixel.
A multilevel mask is an 8 bits per pixel bitmap (with the same size as theframe image). Each byte in the mask represents the transparency level of thecorresponding pixel in the frame image. A value of 255 is fully transparent,and 0 is fully opaque. In EGI version 2.x, you could actually use only twolevels (0 and 255); as of EGI version 3.0, you can define up to 15 additionaltransparency levels.
Note that you can only specify the number of transparency levels; theopacity value of each level of the multilevel masks is not stored. The FLICfile format does not indicate the purpose the additional mask levels either.The number of transparency levels is in the transp_num field inthe FLIC file header (EGI versions priorto 3.0 set this field to zero).The multilevel transparency masks were designed to be used withAniSprite, which allows you to set theopacity for each level (and lets you decide whether the additional levels arefor 'luma' masks or for 'alpha' masks); please look up the AniSpritedocumentation for more information.
A frame can contain both a full image and a delta image. This occurs, forexample when a segment in a FLIC file is both'continued_from' another segment and a launch point, orwhen the 'key_frames' instruction is used. The mask fora frame that contains both a delta image and a full image is always afull mask.
See also the RGN_MASK chunk.
The EGI compiler stores the region of frame differences (see thedif_region instruction of the compiler's script language) bymeans of a grid. In the current release, the grid is composed of square tilesof 16*16 pixels. When a single pixel in a tile changes, all 256 pixels in thattile are flagged as 'modified'.
Two neighbouring tiles that are both flagged as 'modified' are combined intoa single new tile. The edges of the resulting rectangular tiles are alwayssnapped to the grid points. Therefore, each rectangle in a region of framedifferences needs not to enclose the object at pixel precision. However, norectangle will exceed the bounding box of all differences between two frames.
The purpose of a coarse grid is to avoid a large amount of very smallareas. The cost of the overhead for every call to the BitBlt()function for all these areas might be higher than the cost of blitting severalpixels too many.
As of EGI version 2.0, the maximum number of tiles in a region is in thefield max_regions in the FLICfile header.
The flags value is a bit field.
The digitized audio data follows the chunk. The format depends on thevarious flags. If audio is 16-bit, there are two bytes per sample, in LittleEndian (Intel format). In unsigned PCM, the 'silence' level is 128for 8-bit samples and 32768 for 16-bit samples. For stereo audio the samplesfor the left and right channels are interleaved; the sample for the leftchannel precedes the sample for the right channel.
Currently, EGI only supports 8-bit unsigned PCM or 16-bit signed PCM. Theseare the same formats as used in the .WAV and the .VOCfile formats.
An audio stream is often be stored in a single block. The audio starts atthe frame in which the block occurs, and it continues to 'sound' during thedisplaying of the next frames. Audio and animation are not necessarilysynchronized. For these single block audio streams, both bits 3 and 4 in theflags field are set, and overlap is always zero.
The audio stream can also be cut in various blocks. The first block containsenough samples to get from the current frame to the first key frame. The keyframe contains another audio block with enough samples to get to the next keyframe, etc. Here, the bits 3 and 4 of the flags field help toglue the blocks together to a sequential audio stream. Audio and animationshould be synchronized to play back correctly. (The EGI playersynchronizes animation and sound by default if the sound is cut into blocks.)
To avoid gaps in the audio when synchronization is not perfect, each blockcontains more samples than strictly necessary. In the current implementation,EGI adds enough samples to go to one frame after each key frame. When sendinga (next) block to the audio device, you should ignore the firstoverlapbytes from the audio data.
You can jump in the middle of an animation, and this way, you can also jumpin the middle of a multiple block audio stream. In this case, to get a propersynchronization, ignore the overlap field for the first audioblock that you encounter.
A zero-terminated ASCII string follows the chunk header. The USERSTRINGchunk allows an application to store general-purpose strings (both for copyrightinformation as for references to other files or data) in a frame.
The chunk starts (right after the chunk header) with four 16-bit words thatgive the bounding box of the mask (this is similar to the BMP_MASK andRGN_MASK chunks). The values are stored in the following order:x y width height.
The mask data starts behind the bounding box and consists of a list ofnon-overlapping rectangles. This set of rectangles describes the opaque regionof the frame. Each rectangle is composed of four 16-bit words, again in the orderx y width height. The number of rectangles in the region can bedetermined from the size of the chunk.
There is no delta encoding for a region mask, except that if a RGN_MASKchunk is absent from a frame it should be considered equal to the region maskof the previous frame.
Note that the REGION chunk contains acoarse region of changes between two frames. The RGN_MASKchunk is a region of opaque areas of a single frame and it is preciseat pixel level.
See also the BMP_MASK andMLEV_MASK chunks.
Shift chunks are generated when the frame_shift() compression optionis present in the EGI script. As noted in the manual, the frame shiftcompression is effective on animations where the background is panned or whereobjects move over a fixed background, and in particular objects that includetransparency masks.
The shift chunks give pixel counts by which the scan lines in the currentimage must be shifted horizontally and/or vertically to better resemble the'next' image. There are separate shift chunks for the image and for the mask;only multilevel masks (the MLEV_MASK chunk) areapplicable for frame shift compression. That is, if you have region masks,the mask cannot be frame-shifted, but the image in each framecan still benefit from frame shift compression.
The chunk header has the following format:
The first after the fixed chunk header, img_id is zero if the frameshifts apply to the image and 2 if the frame shifts are for the (multilevel)mask. The following byte is for general purpose flags; it is currently alwayszero. The next 16-bit word, prio_list is the size (in bytes) of the'priority list', which is one of the three lists that follow the header.
Following the header are two lists with byte values and a third list withword values a variable-length encoding (technically, it is also a list of bytes).The first two lists have a length that is equal to the height of the frame, thelength of the third list is in the header (described above). All three listsare compressed separately with the compression algorithm that is also used forthe BYTE_RUN chunk.
The first list gives the vertical shifts and the second list gives thehorizontal shifts. Each value in either of these two lists is a signed 8-bitnumber and indicates a shift count. The third list gives the order in which theshifts should be applied. It is variable length because only those lines forwhich the order is important are listed.
See the paper 'EGI compression schemes' for detailsof the frame shift algorithm.
For animations that use frame shift compression, the maximum frame size isrestricted to 16384 × 16384 pixels.
The 'path map' is a planning table that can tell you how to go from one segmentto any other segment, while using only 'known to be good' transitions. A FLICthat has segments has optional cont_image andlast_image markers. When the cont_image marker of one segmentmatches the last_image marker of another segment, that indicates a fluenttransition between the two. The path map forms a matrix of all such transitionsso that the animation path from one segment to another segment is easy to look up.
The goal of the path map is to make 'pose to pose' animation easier, especiallywhen the next pose of the character is determined dynamically or interactively.When pursuing to go from one segment to another segment in a fluent manner,it may be necessary to go via one or more intermediate segments (transitions).The path map records the shortest fluent way to get from the 'current' segmentto any other segment.
The path map is a square matrix with a number of rows and columns that is equalto the number of segments. That is, the path map of an animation with 4 segmentsis a 4×4 matrix. Each entry in the path map is the segment segment number(a two-byte value)of the next segment to take, when using the current segment to index thematrix column and the desired 'goal' segment to index the matrix row.When the value in a matrix cell is -1, no fluent transition is available: eitherthere is no fluent path between the two segments, or you have already arrived atthe goal segment.
As is apparent, one entry in the path map does not indicate a complete path, butonly the next step to take to come closer to the goal segment. Once youarrive at that 'next segment', you do another look-up and get a new 'next step'that is closer to the desired goal segment (and so on). One row in the path mapmatrix does contain an entire path, by the way, but not in a sequentialway. In fact, one row of the matrix contains all paths that lead to onedestination segment.
Frequent errors
Unfortunately, several utilities create FLIC files that do notcompletely comply with the standard. Most FLIC players attemptto detect and silently correct these errors. Below is a list of frequent errorsin FLIC files.
- The colour depth is set to zero.The colour depth must usually be 8. DTA and EGI (starting with version 3.0)support FLIC files with a different colour depth and use a different 'type'value in the FLIC file header. FLX files (15-bpp FLC files that use the samechunks as for 8-bpp FLC files) should have the value 16 in the headerfield for the colour depth, even though they are actually 15-bpp.
- The offsets to the first and second frames are zero in an FLCfile.In fact, it appears that these are FLI files with a FLC header.
- The offset to the second frame is set to an incorrect value.I have seen FLIC files where the offset to the second frame was set to zero,to the offset to the first frame, to the offset to the ring frame, or to aseemingly random value.
- DELTA_FLC chunks are present in files with a FLI header.Since most players are combined FLI/FLC players, this is usually not aproblem. However, a FLIC file with DELTA_FLC chunks shouldhave a FLC header.
- Chunk sizes are not rounded to an even number of bytes.Only very few FLIC players have problems with frames with an odd numberof bytes, but it goes against the 'standard'.
- The sizes of all sub-chunks in a frame chunk do not add togetherto the size in the frame chunk header. Sometimes the frame chunkappears to be padded with extra data behind the last frame. Sometimes thesize a subchunk is incorrect (I have seen this with the FLI_COPYchunk).
- Garbage in reserved fields of a chunk or of the header.Reserved fields in a chunk should be set to zero. Otherwise, the chunksbecome difficult to extend. Players must do their best in estimating (orguessing) whether a field is a valid value for a chunk extension or whetherit is garbage.
- DELTA_FLC chunks with a 'line count' of zero.This is essentially an 8-byte chunk: 6 bytes for the chunk header and twobytes for the count of lines in the chunk. Since this count is zero, no lineswith compressed data follows. Although this is (or should be) valid, theAAPLAY engine crashes when it encounters such blocks. Therefore,utilities should avoid creating these chunks.
- DELTA_FLI is not documented correctly.The document that originates from Autodesk, and which was published with smallmodifications in Dr. Dobb's Journal (see below), claims that:
'Each line begins with two bytes. The first byte contains the startingx position of the data on the line, and the second byte the number ofpackets for the line.'
However, each line starts with only one byte, which is the number ofpackets for the line. - Using 0xF5FA as a 'frame' chunk type. The frame chunk typeshould be 0xF1FA (source Mike Melanson,http://www.pcisys.net/~melanson/).The particular FLIC file that Mike Melanson referred me to was created byDiscreet 3D Studio MAX. I expect that the alternate frame type recordssome implicit (unknown) extra information.
References
- Kent, J.; 'The FLIC File format'; Dr. Dobb's Journal, March 1992 (Volume 18, issue 3).
- A description of the FLIC file format by the original creator of theAutodesk Animator software.
- 'EGI compression schemes'.
- An on-line paper with descriptions ans additional pointers to theextended compression schemes that EGI brings to the FLIC file format.
Overview of FLC File Format
FLC is a file format related to AutoDesk and is created by Autodesk animation software Animator Pro. FLC contains a movie clip relatively large (640×480) movies. FLC is more popular with X11 workstations, PCs and Macs as FLC can be played back at reasonable speeds.
However, it is hard to directly play FLC on Windows PC, Mac, media players or devices. It is even a dream to play FLC in YouTube or edit in iMovie, Windows Movie Maker and more. How can we achieve our dream to play FLC freely?
The answer is simple. We need to convert FLC to MP4, convert FLC to AVI, convert FLC to WMV, convert FLC to FLV, convert FLC to MKV, convert FLC to MOV, convert FLC to MP3 or convert FLC files to other popular video and audio formats with a powerful FLC Player/Converter.
FLC Player- Open and Play FLC Files Easily
FLC Player is a professional FLC Video Player. FLC File Player can help open FLC videos on PC and Mac without any trouble. To play FLC videos with FLC Video Player, we just need to drag and drop the FLC files to the interface of FLC Player and click the “Play” button.
Flv File Type Advantages
In addition, FLC File Player can also play almost all other video and audio formats without any streaming. All you need is to add the files to the FLC playing software and you can easily enjoy them.
How to Convert FLC to MP3, MP4, AVI, FLV, WMV, MOV with FLC Converter?
FLC Video Converter is a professional FLC File Converter which has both Windows version and Mac version so that all the PC and Mac OS X users can get the software.
FLC Converter can is also a nice FLC to AVI Converter, FLC to MP4 Converter, FLC to FLV Converter, FLC to WMV Converter, FLC to MP3 Converter that can help convert FLC popular video formats like convert FLC to AVI, MP4, FLV, WMV, MKV, MOV, VOB, 3GP, WebM, AVCHD, Xvid, DivX, 3GP, etc. and convert FLC to MP3, AIFF, ALAC, FLAC, M4A, AU, RA, WAV, M4A, AC3, ACC, WMA and more with batch mode and fast speed.
With FLC Video Converter, it is quite easy to upload FLC videos to YouTube, Facebook and more video sharing sites for playing and enjoying. This wonderful FLC File Converter can also help open FLC files in media players, portable devices, editing tools including VLC, Windows Media Player, iTunes, iPad, iPhone, Blackberry, Xbox 360, PSP, PS3, Creative Zen, Zune, iMovie, Windows Movie Maker, Final Cut Pro and more. FLC Converter can also help burn FLC into DVD as you like.
Besides, this wonderful FLC to MP4 Converter is able to do some basic editing like cut FLC files, adjust FLC files screen zoom, rotate FLC videos, add watermark or subtitles, adjust volume/bitrate/codec and more.
Be Ready: Free Download FLC Video Converter
Get FLC Converter (For Windows, For Mac) to your computer. Install it when finish downloading.
Step 1 Load FLC Files to FLC File Converter
Click the “Add File” button to load FLC files. You may also drag and drag FLC videos into the FLC Player if you prefer.
Step 2 Set the Output Format as You Wish
Find “Profile” drop-down button to choose the output format.
You may also choose the file format form “iPad”, “iPhone”, “iPod”, “BlackBerry”, “Samsung”, and “Android” from FLC Video Converter if you have such needs.
Notice: You can go to “Trim” “Crop” “Effect” “Image” “Subtitle” “Watermark” tab to cut videos, adjust video zoom, add subtitles to videos, and add watermark , adjust image brightness and more with FLC File Player.
You can also go to “Setting …” tab to adjust video and audio bitrate/codec/resolution, adjust audio volumes and more with FLC to AVI Converter.
Step 3 Convert FLC Videos with FLC to MP3 Converter
Click the “Convert” button to start FLC file converting.
Tools to Play FLC Files
- FLC Player/Converter: Play FLC files, convert FLC files to play FLC files anywhere any place, download YouTube videos, edit FLC file.
- Apple QuickTime: Play FLC files.
Hot Tags
mvc player free download, mp4 to dpg, fbr player software, m3u8 to mp4, tvs converter, youtube to mp3 converter for windows media, ksd file player, ifv file player free download, mtv converter mp3