From c84a18b2f4a27cdeed6121d86c83eefa7600300a Mon Sep 17 00:00:00 2001 From: David Capello Date: Tue, 6 Dec 2016 16:32:06 -0300 Subject: [PATCH] Convert Aseprite file format specs into a .md file --- docs/{files/ase.txt => ase-file-specs.md} | 235 ++++++++++----------- docs/files/fli.txt | 243 ---------------------- docs/files/msk.txt | 51 ----- docs/files/pic.txt | 71 ------- docs/files/picpro.txt | 92 -------- 5 files changed, 115 insertions(+), 577 deletions(-) rename docs/{files/ase.txt => ase-file-specs.md} (59%) delete mode 100644 docs/files/fli.txt delete mode 100644 docs/files/msk.txt delete mode 100644 docs/files/pic.txt delete mode 100644 docs/files/picpro.txt diff --git a/docs/files/ase.txt b/docs/ase-file-specs.md similarity index 59% rename from docs/files/ase.txt rename to docs/ase-file-specs.md index 66d0a84d4..2d39a3699 100644 --- a/docs/files/ase.txt +++ b/docs/ase-file-specs.md @@ -1,39 +1,37 @@ -ASE Files (.ASE) Format description -Copyright (C) 2001-2016 by David Capello ----------------------------------------------------------------------- +Aseprite File Format (.ase/.aseprite) Specifications +==================================================== + +> Copyright (C) 2001-2016 by David Capello + +1. [References](#1-references) +2. [Introduction](#2-introduction) +3. [Header](#3-header) +4. [Frames](#4-frames) +5. [Chunk Types](#5-chunk-types) +6. [File Format Changes](#6-file-format-changes) 1. References -2. Introduction -3. Header -4. Frames -5. New chunk types -6. File Format Changes - -======================================== -1. References -======================================== +------------- ASE files use Intel (little-endian) byte order. -BYTE An 8-bit unsigned integer value -WORD A 16-bit unsigned integer value -SIGNED WORD A 16-bit signed integer value -DWORD A 32-bit unsigned integer value -BYTE[n] "n" bytes. -STRING length=WORD (how many characters to read next) - string=BYTE[length] - The \0 character isn't included. -PIXEL Pixel format: - - In RGB images, each pixel have 4 bytes in - this order Red, Green, Blue, Alpha. - - In Grayscale images, each pixel have 2 bytes - in the order Value, Alpha. - - In Indexed images, each pixel uses 1 byte (the index). +Data Type | Details | +--------------- | -------------------------------- | +BYTE | An 8-bit unsigned integer value +WORD | A 16-bit unsigned integer value +SIGNED WORD | A 16-bit signed integer value +DWORD | A 32-bit unsigned integer value +BYTE[n] | "n" bytes. +STRING | WORD: string length (number of bytes) + | BYTE[length]: characters (in UTF-8) + | The \0 character is not included. +PIXEL | One pixel, depending on the image pixel format: + | **RGB**: Each pixel have 4 bytes in this order Red, Green, Blue, Alpha. + | **Grayscale**: Each pixel have 2 bytes in the order Value, Alpha. + | **Indexed**: Each pixel uses 1 byte (the index). - -======================================== 2. Introduction -======================================== +--------------- The format is much like FLI/FLC files, but with different magic number and differents chunks. Also, the color depth can be 8, 16 or 32 for @@ -43,78 +41,71 @@ type=11 or type=4). For color depths more than 8bpp, palettes are optional. See fli.txt for details. To read the sprite: -* Read the ASE header (section 3) -* For each frame do (how many frames? the ASE header has that - information): - + Read the frame header (section 4) - + For each chunk in this frame (how many chunks? the frame header - has that information) - - Read the chunk (it should be layer information, a cel or a - palette) +* Read the [ASE header](#3-header) +* For each frame do (how many frames? the ASE header has that information): + + Read the [frame header](#4-frames) + + For each chunk in this frame (how many chunks? the frame header has that information) + - Read the chunk (it should be layer information, a cel or a palette) -======================================== 3. Header -======================================== +--------- -A 128-byte header (same as FLC/FLI header, but with other magic -number): +A 128-byte header (same as FLC/FLI header, but with other magic number): -DWORD File size -WORD Magic number (0xA5E0) -WORD Frames -WORD Width in pixels -WORD Height in pixels -WORD Color depth (bits per pixel) - 32 bpp = RGBA - 16 bpp = Grayscale - 8 bpp = Indexed -DWORD Flags: - 1 = Layer opacity has valid value -WORD Speed (milliseconds between frame, like in FLC files) - DEPRECATED: You should use the frame duration - field from each frame header -DWORD Set be 0 -DWORD Set be 0 -BYTE Palette entry (index) which represent transparent - color in all non-background layers (only for Indexed - sprites). -BYTE[3] Ignore these bytes -WORD Number of colors (0 means 256 for old sprites) -BYTE[94] For future (set to zero) +Field | Details | +------------- | -------------------------------- | +DWORD | File size +WORD | Magic number (0xA5E0) +WORD | Frames +WORD | Width in pixels +WORD | Height in pixels +WORD | Color depth (bits per pixel) + | 32 bpp = RGBA + | 16 bpp = Grayscale + | 8 bpp = Indexed +DWORD | Flags: + | 1 = Layer opacity has valid value +WORD | Speed (milliseconds between frame, like in FLC files) **DEPRECATED:** You should use the frame duration field from each frame header +DWORD | Set be 0 +DWORD | Set be 0 +BYTE | Palette entry (index) which represent transparent color in all non-background layers (only for Indexed sprites). +BYTE[3] | Ignore these bytes +WORD | Number of colors (0 means 256 for old sprites) +BYTE[94] | For future (set to zero) - -======================================== 4. Frames -======================================== +--------- After the header come the "frames" data. Each frame has this little header of 16 bytes: - DWORD Bytes in this frame - WORD Magic number (always 0xF1FA) - WORD Number of "chunks" in this frame - WORD Frame duration (in milliseconds) - BYTE[6] For future (set to zero) +Field | Details | +----------- | -------------------------------- | +DWORD | Bytes in this frame +WORD | Magic number (always 0xF1FA) +WORD | Number of "chunks" in this frame +WORD | Frame duration (in milliseconds) +BYTE[6] | For future (set to zero) Then each chunk format is: - DWORD Chunk size - WORD Chunk type - BYTE[] Chunk data +Field | Details | +----------- | -------------------------------- | +DWORD | Chunk size +WORD | Chunk type +BYTE[] | Chunk data +5. Chunk Types +-------------- -======================================== -5. Chunk types -======================================== - -Old palette chunk (0x0004) ----------------------------------------- +### Old palette chunk (0x0004) Ignore this chunk if you find the new palette chunk (0x2019) Aseprite v1.1 saves both chunks 0x0004 and 0x2019 just for backward compatibility. +``` WORD Number of packets + For each packet BYTE Number of palette entries to skip from the last packet (start from 0) @@ -123,13 +114,13 @@ compatibility. BYTE Red (0-255) BYTE Green (0-255) BYTE Blue (0-255) +``` - -Old palette chunk (0x0011) ----------------------------------------- +### Old palette chunk (0x0011) Ignore this chunk if you find the new palette chunk (0x2019) +``` WORD Number of packets + For each packet BYTE Number of palette entries to skip from the last packet (start from 0) @@ -138,14 +129,14 @@ Ignore this chunk if you find the new palette chunk (0x2019) BYTE Red (0-63) BYTE Green (0-63) BYTE Blue (0-63) +``` - -Layer Chunk (0x2004) ----------------------------------------- +### Layer Chunk (0x2004) In the first frame should be a set of layer chunks to determine the entire layers layout: +``` WORD Flags: 1 = Visible 2 = Editable @@ -177,14 +168,14 @@ Layer Chunk (0x2004) Note: valid only if file header flags field has bit 1 set BYTE[3] For future (set to zero) STRING Layer name +``` - -Cel Chunk (0x2005) ----------------------------------------- +### Cel Chunk (0x2005) This chunk determine where to put a cel in the specified layer/frame. +``` WORD Layer index (see NOTE.2) SIGNED WORD X position SIGNED WORD Y position @@ -210,11 +201,11 @@ Cel Chunk (0x2005) BYTE[] Compressed "Raw Cel" data. Details about the compression method: http://www.ietf.org/rfc/rfc1951.txt +``` +### Mask Chunk (0x2016) DEPRECATED -Mask Chunk (0x2016) DEPRECATED ----------------------------------------- - +``` SIGNED WORD X position SIGNED WORD Y position WORD Width @@ -224,17 +215,17 @@ Mask Chunk (0x2016) DEPRECATED BYTE[] Bit map data (size = height*((width+7)/8)) Each byte contains 8 pixels (the leftmost pixels are packed into the high order bits) +``` -Path Chunk (0x2017) ----------------------------------------- +### Path Chunk (0x2017) Never used. -Frame Tags Chunk (0x2018) ----------------------------------------- +### Frame Tags Chunk (0x2018) +``` WORD Number of tags BYTE[8] For future (set to zero) + For each tag @@ -248,11 +239,11 @@ Frame Tags Chunk (0x2018) BYTE[3] RGB values of the tag color BYTE Extra byte (zero) STRING Tag name +``` +### Palette Chunk (0x2019) -Palette Chunk (0x2019) ----------------------------------------- - +``` DWORD New palette size (total number of entries) DWORD First color index to change DWORD Last color index to change @@ -266,15 +257,15 @@ Palette Chunk (0x2019) BYTE Alpha (0-255) + If has name bit in entry flags STRING Color name +``` - -User Data Chunk (0x2020) ----------------------------------------- +### User Data Chunk (0x2020) Insert this user data in the last read chunk. E.g. If we've read a layer, this user data belongs to that layer, if we've read a cel, it belongs to that cel, etc. +``` DWORD Flags 1 = Has text 2 = Has color @@ -285,14 +276,16 @@ belongs to that cel, etc. BYTE Color Green (0-255) BYTE Color Blue (0-255) BYTE Color Alpha (0-255) +``` +### Notes -Notes ----------------------------------------- +#### NOTE.1 -NOTE.1: The child level is used to show the relationship of this - layer with the last one read, for example: +The child level is used to show the relationship of this layer with +the last one read, for example: +``` Layer name and hierarchy Child Level ----------------------------------------------- - Background 0 @@ -301,11 +294,14 @@ NOTE.1: The child level is used to show the relationship of this |- My set1 1 | `- Layer2 2 `- Layer3 1 +``` +#### NOTE.2 -NOTE.2: The layer index is a number to identify any layer in the - sprite, for example: +The layer index is a number to identify any layer in the sprite, for +example: +``` Layer name and hierarchy Layer index ----------------------------------------------- - Background 0 @@ -314,18 +310,17 @@ NOTE.2: The layer index is a number to identify any layer in the |- My set1 3 | `- Layer2 4 `- Layer3 5 +``` +6. File Format Changes +---------------------- -======================================== -File Format Changes -======================================== +1. The first change from the first release of the new .ase format, + is the new frame duration field. This is because now each frame + can have different duration. - 1) The first change from the first release of the new .ase format, - is the new frame duration field. This is because now each frame - can have different duration. - - How to read both formats (old and new one)? You should set all - frames durations to the "speed" field read from the main ASE - header. Then, if you found a frame with the frame-duration - field > 0, you should update the duration of the frame with - that value. + How to read both formats (old and new one)? You should set all + frames durations to the "speed" field read from the main ASE + header. Then, if you found a frame with the frame-duration + field > 0, you should update the duration of the frame with + that value. diff --git a/docs/files/fli.txt b/docs/files/fli.txt deleted file mode 100644 index 2df39409c..000000000 --- a/docs/files/fli.txt +++ /dev/null @@ -1,243 +0,0 @@ - -Flic Files (.FLI) Format description: - - 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 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. - - 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 -size_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. - ------------------------------------------------------------------------ -And here's the PRO extensions: ------------------------------------------------------------------------ - -This is supplemental info on the AutoDesk Animator FLI and FLC formats. - -The following is an attempt at describing the newer chunks and frames -that are not described in the Turbo C FLI library documentation. - - Chunk type Chunk ID - ---------- ----------- - FLI_DELTA 7 (decimal) - - First WORD (16 bits) is the number of compressed lines to follow. Next - is the data for the changing lines themselves, always starting with the - first line. Each line is compressed individually. - - The first WORD (16 bits) of a compressed line is the number of packets in - 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: - - 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 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. - - Chunk type Chunk ID - ---------- ----------- - FLI_256_COLOR 4 (decimal) - - The first WORD is the number of packets in this chunk. This is followed - 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). - - The only difference between a FLI_256_COLOR chunk (type 4 decimal) and a - 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. - - NOTE: WORD refer to a 16 bit int in INTEL (Little Endian) format. - WORDS refer to two-bytes (16 bits) of consecutive data. (Big Endian) - - .FLC special frames and chunks - - FLC's may contain all the above chunks plus one other: - - Chunk type Chunk ID - ---------- ----------- - FLI_MINI 18 (decimal) 12 (Hex) - - From what I understand, this is a miniture 64 x 32 version of the first - frame in FLI_BRUN format, used as an button for selecting flc's from - within Animator Pro. Simply do nothing with this chunk. - - FLC New Frame - - FLC's also contains a frame with the magic bytes set to hex 00A1. This - 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. - - - NOTE: When reading the FLI header on the newer FLI and FLC files, the - 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. - - Allowable screen sizes include: - - 320 x 200, 640 x 480, 800 x 600, 1280 x 1024 - - - NOTE: the delay value between frames appears to be in 1000th's of a - second instead of 70th's. - -If you have any questions or more info on the FLI or FLC formats, -please let me know. - -Mike Haaland -(corrected by P. Oliver 30 May 1997 using information supplied by Reeves Hall) - -CompuServe : 72300,1433 -Delphi : MikeHaaland -Internet : mike@htsmm1.las-vegas.nv.us -Usenet : ...!htsmm1.las-vegas.nv.us!mike diff --git a/docs/files/msk.txt b/docs/files/msk.txt deleted file mode 100644 index e7b65ee8b..000000000 --- a/docs/files/msk.txt +++ /dev/null @@ -1,51 +0,0 @@ -MSK Format -Intel byte order - -Information from File Format List 2.0 by Max Maischein. - ---------!-CONTACT_INFO---------------------- -If you notice any mistakes or omissions, please let me know! It is only -with YOUR help that the list can continue to grow. Please send -all changes to me rather than distributing a modified version of the list. - -This file has been authored in the style of the INTERxxy.* file list -by Ralf Brown, and uses almost the same format. - -Please read the file FILEFMTS.1ST before asking me any questions. You may find -that they have already been addressed. - - Max Maischein - -Max Maischein, 2:244/1106.17 -Max_Maischein@spam.fido.de -corion@informatik.uni-frankfurt.de -Corion on #coders@IRC ---------!-DISCLAIMER------------------------ -DISCLAIMER: THIS MATERIAL IS PROVIDED "AS IS". I verify the information -contained in this list to the best of my ability, but I cannot be held -responsible for any problems caused by use or misuse of the information, -especially for those file formats foreign to the PC, like AMIGA or SUN file -formats. If an information it is marked "guesswork" or undocumented, you -should check it carefully to make sure your program will not break with -an unexpected value (and please let me know whether or not it works -the same way). - -Information marked with "???" is known to be incomplete or guesswork. - -Some file formats were not released by their creators, others are regarded -as proprietary, which means that if your programs deal with them, you might -be looking for trouble. I don't care about this. --------------------------------------------- - -The MSK files are mask files used by the Autodesk Animator and Animator Pro -packages. Two types of MSK files exist. The Animator Pro version is simply a PIC -file with the depth 1; A MSK file created by the original Animator is exactly -8000 bytes long. There is no file header or other control information in the -file. It contains the image bit map, 1 bit per pixel, with the leftmost pixels -packed into the high order bits of each byte. The size of the image is fixed at -320x200. The image is stored left-to-right, top-to-bottom. - -EXTENSION:MSK -OCCURENCES:PC -PROGRAMS:Autodesk Animator -SEE ALSO:PIC,FLIc diff --git a/docs/files/pic.txt b/docs/files/pic.txt deleted file mode 100644 index 9375f5f01..000000000 --- a/docs/files/pic.txt +++ /dev/null @@ -1,71 +0,0 @@ -PIC Format -Intel byte order - -Information from File Format List 2.0 by Max Maischein. - ---------!-CONTACT_INFO---------------------- -If you notice any mistakes or omissions, please let me know! It is only -with YOUR help that the list can continue to grow. Please send -all changes to me rather than distributing a modified version of the list. - -This file has been authored in the style of the INTERxxy.* file list -by Ralf Brown, and uses almost the same format. - -Please read the file FILEFMTS.1ST before asking me any questions. You may find -that they have already been addressed. - - Max Maischein - -Max Maischein, 2:244/1106.17 -Max_Maischein@spam.fido.de -corion@informatik.uni-frankfurt.de -Corion on #coders@IRC ---------!-DISCLAIMER------------------------ -DISCLAIMER: THIS MATERIAL IS PROVIDED "AS IS". I verify the information -contained in this list to the best of my ability, but I cannot be held -responsible for any problems caused by use or misuse of the information, -especially for those file formats foreign to the PC, like AMIGA or SUN file -formats. If an information it is marked "guesswork" or undocumented, you -should check it carefully to make sure your program will not break with -an unexpected value (and please let me know whether or not it works -the same way). - -Information marked with "???" is known to be incomplete or guesswork. - -Some file formats were not released by their creators, others are regarded -as proprietary, which means that if your programs deal with them, you might -be looking for trouble. I don't care about this. --------------------------------------------- - -PIC files contain images in an uncompressed format. Both the original Animator -and Animator Pro from Autodesk produce PIC files. The file formats are -different; Animator Pro produces a hierarchial block oriented file, while the -original Animator file is a simpler fixed format. See PIC(Pro) for further -information on the Animator Pro PIC format. - -The original Animator uses this format to store a single-frame picture image. -This format description applies to both PIC and original Animator CEL files. The -file begins with a 32 byte header, as follows: - -OFFSET Count TYPE Description -0000h 1 word ID=9119h -0002h 1 word Width of image; PIC files have always a width - of 320, CEL images may have any value. -0004h 1 word Height of image, 200 for a PIC, any value for - a CEL file. -0006h 1 word X offset of image, always 0 for a PIC image, - may be nonzero in a CEL image. -0008h 1 word Y offset of image. Zero for a PIC file. -000Ah 1 byte Bits per pixel (8) -000Bh 1 byte Compresion flag, always zero -000Ch 1 dword Size of the image data in bytes -0010h 16 byte reserved(0) - -Immediately following the header is the color map. It contains all 256 palette -entries in rgb order. Each of the r, g, and b components is a single byte in the -range of 0-63. Following the color palette is the image data, one byte per -pixel, from left to right, top to bottom. -EXTENSION:PIC,CEL -OCCURENCES:PC -PROGRAMS:Autodesk Animator -SEE ALSO:CEL,FLIc,PIC(PRO) diff --git a/docs/files/picpro.txt b/docs/files/picpro.txt deleted file mode 100644 index de6271857..000000000 --- a/docs/files/picpro.txt +++ /dev/null @@ -1,92 +0,0 @@ -PIC(PRO) Format -Intel byte order - -Information from File Format List 2.0 by Max Maischein. - ---------!-CONTACT_INFO---------------------- -If you notice any mistakes or omissions, please let me know! It is only -with YOUR help that the list can continue to grow. Please send -all changes to me rather than distributing a modified version of the list. - -This file has been authored in the style of the INTERxxy.* file list -by Ralf Brown, and uses almost the same format. - -Please read the file FILEFMTS.1ST before asking me any questions. You may find -that they have already been addressed. - - Max Maischein - -Max Maischein, 2:244/1106.17 -Max_Maischein@spam.fido.de -corion@informatik.uni-frankfurt.de -Corion on #coders@IRC ---------!-DISCLAIMER------------------------ -DISCLAIMER: THIS MATERIAL IS PROVIDED "AS IS". I verify the information -contained in this list to the best of my ability, but I cannot be held -responsible for any problems caused by use or misuse of the information, -especially for those file formats foreign to the PC, like AMIGA or SUN file -formats. If an information it is marked "guesswork" or undocumented, you -should check it carefully to make sure your program will not break with -an unexpected value (and please let me know whether or not it works -the same way). - -Information marked with "???" is known to be incomplete or guesswork. - -Some file formats were not released by their creators, others are regarded -as proprietary, which means that if your programs deal with them, you might -be looking for trouble. I don't care about this. --------------------------------------------- - -This format description applies to both PIC and MSK files created with the -Autodesk Animator Pro package. The file begins with a 64-byte header defined -as follows: - -Offset Length Name Description -0000h 1 dword The size of the whole file including the size - of this header. -0004h 1 word ID=9500h -0006h 1 word Width of the image -0008h 1 word Height of the image -000Ah 1 word X offset of image -000Ch 1 word Y offset of image -000Eh 1 dword User ID, set to zero -0012h 1 byte Bits per pixel (8 for PIC, 1 for MSK) -0013h 45 byte reserved (0) - -Following the file header are the data blocks for the image. Each data block -within a PIC or MSK file is formatted as follows: - -OFFSET Count TYPE Description -0000h 1 dword The size of the block, including this header. -0004h 1 word Data type ID : - 0 - Color palette info - 1 - Byte-per-pixel image data - 2 - Bit-per-pixel mask data -0006h ? byte Data - -The type values in the block headers indicate what type of graphics data the -block contains. - -In a PIC_CMAP block, the first 2-byte word is a version code; -currently this is set to zero. Following the version word are all 256 palette -entries in rgb order. Each of the r, g, and b components is a single byte in the -range of 0-255. This type of block appears in PIC files; there will generally be -no color map block in a MSK file. - -In a PIC_BYTEPIXELS block, the image data appears immediately following the -6-byte block header. The data is stored as one byte per pixel, in left-to-right, -topD to-bottom sequence. - -In a PIC_BITPIXELS block, the bitmap data appears immediately following the -6-byte block header. The data is stored as bits packed into bytes such that the -leftmost bits appear in the high-order positions of each byte. The bits are -stored in left-to-right, top-to bottom sequence. When the width of the bitmap is -not a multiple of 8, there will be unused bits in the low order positions of the -last byte on each line. The number of bytes per line is ((width+7)/8). This type -of block appears in MSK files. - -EXTENSION:PIC,MSK -OCCURENCES:PC -PROGRAMS:Autodesk Animator Pro -REFERENCE: -SEE ALSO:PIC,FLT