mirror of
https://github.com/aseprite/aseprite.git
synced 2025-01-28 18:32:50 +00:00
Convert Aseprite file format specs into a .md file
This commit is contained in:
parent
b7f773566e
commit
c84a18b2f4
@ -1,39 +1,37 @@
|
|||||||
ASE Files (.ASE) Format description
|
Aseprite File Format (.ase/.aseprite) Specifications
|
||||||
Copyright (C) 2001-2016 by David Capello
|
====================================================
|
||||||
----------------------------------------------------------------------
|
|
||||||
|
> 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
|
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.
|
ASE files use Intel (little-endian) byte order.
|
||||||
|
|
||||||
BYTE An 8-bit unsigned integer value
|
Data Type | Details |
|
||||||
WORD A 16-bit unsigned integer value
|
--------------- | -------------------------------- |
|
||||||
SIGNED WORD A 16-bit signed integer value
|
BYTE | An 8-bit unsigned integer value
|
||||||
DWORD A 32-bit unsigned integer value
|
WORD | A 16-bit unsigned integer value
|
||||||
BYTE[n] "n" bytes.
|
SIGNED WORD | A 16-bit signed integer value
|
||||||
STRING length=WORD (how many characters to read next)
|
DWORD | A 32-bit unsigned integer value
|
||||||
string=BYTE[length]
|
BYTE[n] | "n" bytes.
|
||||||
The \0 character isn't included.
|
STRING | WORD: string length (number of bytes)
|
||||||
PIXEL Pixel format:
|
| BYTE[length]: characters (in UTF-8)
|
||||||
- In RGB images, each pixel have 4 bytes in
|
| The \0 character is not included.
|
||||||
this order Red, Green, Blue, Alpha.
|
PIXEL | One pixel, depending on the image pixel format:
|
||||||
- In Grayscale images, each pixel have 2 bytes
|
| **RGB**: Each pixel have 4 bytes in this order Red, Green, Blue, Alpha.
|
||||||
in the order Value, Alpha.
|
| **Grayscale**: Each pixel have 2 bytes in the order Value, Alpha.
|
||||||
- In Indexed images, each pixel uses 1 byte (the index).
|
| **Indexed**: Each pixel uses 1 byte (the index).
|
||||||
|
|
||||||
|
|
||||||
========================================
|
|
||||||
2. Introduction
|
2. Introduction
|
||||||
========================================
|
---------------
|
||||||
|
|
||||||
The format is much like FLI/FLC files, but with different magic number
|
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
|
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.
|
optional. See fli.txt for details.
|
||||||
|
|
||||||
To read the sprite:
|
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
|
3. Header
|
||||||
========================================
|
---------
|
||||||
|
|
||||||
A 128-byte header (same as FLC/FLI header, but with other magic
|
A 128-byte header (same as FLC/FLI header, but with other magic number):
|
||||||
number):
|
|
||||||
|
|
||||||
DWORD File size
|
Field | Details |
|
||||||
WORD Magic number (0xA5E0)
|
------------- | -------------------------------- |
|
||||||
WORD Frames
|
DWORD | File size
|
||||||
WORD Width in pixels
|
WORD | Magic number (0xA5E0)
|
||||||
WORD Height in pixels
|
WORD | Frames
|
||||||
WORD Color depth (bits per pixel)
|
WORD | Width in pixels
|
||||||
32 bpp = RGBA
|
WORD | Height in pixels
|
||||||
16 bpp = Grayscale
|
WORD | Color depth (bits per pixel)
|
||||||
8 bpp = Indexed
|
| 32 bpp = RGBA
|
||||||
DWORD Flags:
|
| 16 bpp = Grayscale
|
||||||
1 = Layer opacity has valid value
|
| 8 bpp = Indexed
|
||||||
WORD Speed (milliseconds between frame, like in FLC files)
|
DWORD | Flags:
|
||||||
DEPRECATED: You should use the frame duration
|
| 1 = Layer opacity has valid value
|
||||||
field from each frame header
|
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
|
||||||
DWORD Set be 0
|
DWORD | Set be 0
|
||||||
BYTE Palette entry (index) which represent transparent
|
BYTE | Palette entry (index) which represent transparent color in all non-background layers (only for Indexed sprites).
|
||||||
color in all non-background layers (only for Indexed
|
BYTE[3] | Ignore these bytes
|
||||||
sprites).
|
WORD | Number of colors (0 means 256 for old sprites)
|
||||||
BYTE[3] Ignore these bytes
|
BYTE[94] | For future (set to zero)
|
||||||
WORD Number of colors (0 means 256 for old sprites)
|
|
||||||
BYTE[94] For future (set to zero)
|
|
||||||
|
|
||||||
|
|
||||||
========================================
|
|
||||||
4. Frames
|
4. Frames
|
||||||
========================================
|
---------
|
||||||
|
|
||||||
After the header come the "frames" data. Each frame has this little
|
After the header come the "frames" data. Each frame has this little
|
||||||
header of 16 bytes:
|
header of 16 bytes:
|
||||||
|
|
||||||
DWORD Bytes in this frame
|
Field | Details |
|
||||||
WORD Magic number (always 0xF1FA)
|
----------- | -------------------------------- |
|
||||||
WORD Number of "chunks" in this frame
|
DWORD | Bytes in this frame
|
||||||
WORD Frame duration (in milliseconds)
|
WORD | Magic number (always 0xF1FA)
|
||||||
BYTE[6] For future (set to zero)
|
WORD | Number of "chunks" in this frame
|
||||||
|
WORD | Frame duration (in milliseconds)
|
||||||
|
BYTE[6] | For future (set to zero)
|
||||||
|
|
||||||
Then each chunk format is:
|
Then each chunk format is:
|
||||||
|
|
||||||
DWORD Chunk size
|
Field | Details |
|
||||||
WORD Chunk type
|
----------- | -------------------------------- |
|
||||||
BYTE[] Chunk data
|
DWORD | Chunk size
|
||||||
|
WORD | Chunk type
|
||||||
|
BYTE[] | Chunk data
|
||||||
|
|
||||||
|
5. Chunk Types
|
||||||
|
--------------
|
||||||
|
|
||||||
========================================
|
### Old palette chunk (0x0004)
|
||||||
5. Chunk types
|
|
||||||
========================================
|
|
||||||
|
|
||||||
Old palette chunk (0x0004)
|
|
||||||
----------------------------------------
|
|
||||||
|
|
||||||
Ignore this chunk if you find the new palette chunk (0x2019) Aseprite
|
Ignore this chunk if you find the new palette chunk (0x2019) Aseprite
|
||||||
v1.1 saves both chunks 0x0004 and 0x2019 just for backward
|
v1.1 saves both chunks 0x0004 and 0x2019 just for backward
|
||||||
compatibility.
|
compatibility.
|
||||||
|
|
||||||
|
```
|
||||||
WORD Number of packets
|
WORD Number of packets
|
||||||
+ For each packet
|
+ For each packet
|
||||||
BYTE Number of palette entries to skip from the last packet (start from 0)
|
BYTE Number of palette entries to skip from the last packet (start from 0)
|
||||||
@ -123,13 +114,13 @@ compatibility.
|
|||||||
BYTE Red (0-255)
|
BYTE Red (0-255)
|
||||||
BYTE Green (0-255)
|
BYTE Green (0-255)
|
||||||
BYTE Blue (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)
|
Ignore this chunk if you find the new palette chunk (0x2019)
|
||||||
|
|
||||||
|
```
|
||||||
WORD Number of packets
|
WORD Number of packets
|
||||||
+ For each packet
|
+ For each packet
|
||||||
BYTE Number of palette entries to skip from the last packet (start from 0)
|
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 Red (0-63)
|
||||||
BYTE Green (0-63)
|
BYTE Green (0-63)
|
||||||
BYTE Blue (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
|
In the first frame should be a set of layer chunks to determine the
|
||||||
entire layers layout:
|
entire layers layout:
|
||||||
|
|
||||||
|
```
|
||||||
WORD Flags:
|
WORD Flags:
|
||||||
1 = Visible
|
1 = Visible
|
||||||
2 = Editable
|
2 = Editable
|
||||||
@ -177,14 +168,14 @@ Layer Chunk (0x2004)
|
|||||||
Note: valid only if file header flags field has bit 1 set
|
Note: valid only if file header flags field has bit 1 set
|
||||||
BYTE[3] For future (set to zero)
|
BYTE[3] For future (set to zero)
|
||||||
STRING Layer name
|
STRING Layer name
|
||||||
|
```
|
||||||
|
|
||||||
|
### Cel Chunk (0x2005)
|
||||||
Cel Chunk (0x2005)
|
|
||||||
----------------------------------------
|
|
||||||
|
|
||||||
This chunk determine where to put a cel in the specified
|
This chunk determine where to put a cel in the specified
|
||||||
layer/frame.
|
layer/frame.
|
||||||
|
|
||||||
|
```
|
||||||
WORD Layer index (see NOTE.2)
|
WORD Layer index (see NOTE.2)
|
||||||
SIGNED WORD X position
|
SIGNED WORD X position
|
||||||
SIGNED WORD Y position
|
SIGNED WORD Y position
|
||||||
@ -210,11 +201,11 @@ Cel Chunk (0x2005)
|
|||||||
BYTE[] Compressed "Raw Cel" data. Details about the
|
BYTE[] Compressed "Raw Cel" data. Details about the
|
||||||
compression method:
|
compression method:
|
||||||
http://www.ietf.org/rfc/rfc1951.txt
|
http://www.ietf.org/rfc/rfc1951.txt
|
||||||
|
```
|
||||||
|
|
||||||
|
### Mask Chunk (0x2016) DEPRECATED
|
||||||
|
|
||||||
Mask Chunk (0x2016) DEPRECATED
|
```
|
||||||
----------------------------------------
|
|
||||||
|
|
||||||
SIGNED WORD X position
|
SIGNED WORD X position
|
||||||
SIGNED WORD Y position
|
SIGNED WORD Y position
|
||||||
WORD Width
|
WORD Width
|
||||||
@ -224,17 +215,17 @@ Mask Chunk (0x2016) DEPRECATED
|
|||||||
BYTE[] Bit map data (size = height*((width+7)/8))
|
BYTE[] Bit map data (size = height*((width+7)/8))
|
||||||
Each byte contains 8 pixels (the leftmost pixels are
|
Each byte contains 8 pixels (the leftmost pixels are
|
||||||
packed into the high order bits)
|
packed into the high order bits)
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
Path Chunk (0x2017)
|
### Path Chunk (0x2017)
|
||||||
----------------------------------------
|
|
||||||
|
|
||||||
Never used.
|
Never used.
|
||||||
|
|
||||||
|
|
||||||
Frame Tags Chunk (0x2018)
|
### Frame Tags Chunk (0x2018)
|
||||||
----------------------------------------
|
|
||||||
|
|
||||||
|
```
|
||||||
WORD Number of tags
|
WORD Number of tags
|
||||||
BYTE[8] For future (set to zero)
|
BYTE[8] For future (set to zero)
|
||||||
+ For each tag
|
+ For each tag
|
||||||
@ -248,11 +239,11 @@ Frame Tags Chunk (0x2018)
|
|||||||
BYTE[3] RGB values of the tag color
|
BYTE[3] RGB values of the tag color
|
||||||
BYTE Extra byte (zero)
|
BYTE Extra byte (zero)
|
||||||
STRING Tag name
|
STRING Tag name
|
||||||
|
```
|
||||||
|
|
||||||
|
### Palette Chunk (0x2019)
|
||||||
|
|
||||||
Palette Chunk (0x2019)
|
```
|
||||||
----------------------------------------
|
|
||||||
|
|
||||||
DWORD New palette size (total number of entries)
|
DWORD New palette size (total number of entries)
|
||||||
DWORD First color index to change
|
DWORD First color index to change
|
||||||
DWORD Last color index to change
|
DWORD Last color index to change
|
||||||
@ -266,15 +257,15 @@ Palette Chunk (0x2019)
|
|||||||
BYTE Alpha (0-255)
|
BYTE Alpha (0-255)
|
||||||
+ If has name bit in entry flags
|
+ If has name bit in entry flags
|
||||||
STRING Color name
|
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
|
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
|
layer, this user data belongs to that layer, if we've read a cel, it
|
||||||
belongs to that cel, etc.
|
belongs to that cel, etc.
|
||||||
|
|
||||||
|
```
|
||||||
DWORD Flags
|
DWORD Flags
|
||||||
1 = Has text
|
1 = Has text
|
||||||
2 = Has color
|
2 = Has color
|
||||||
@ -285,14 +276,16 @@ belongs to that cel, etc.
|
|||||||
BYTE Color Green (0-255)
|
BYTE Color Green (0-255)
|
||||||
BYTE Color Blue (0-255)
|
BYTE Color Blue (0-255)
|
||||||
BYTE Color Alpha (0-255)
|
BYTE Color Alpha (0-255)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Notes
|
||||||
|
|
||||||
Notes
|
#### NOTE.1
|
||||||
----------------------------------------
|
|
||||||
|
|
||||||
NOTE.1: The child level is used to show the relationship of this
|
The child level is used to show the relationship of this layer with
|
||||||
layer with the last one read, for example:
|
the last one read, for example:
|
||||||
|
|
||||||
|
```
|
||||||
Layer name and hierarchy Child Level
|
Layer name and hierarchy Child Level
|
||||||
-----------------------------------------------
|
-----------------------------------------------
|
||||||
- Background 0
|
- Background 0
|
||||||
@ -301,11 +294,14 @@ NOTE.1: The child level is used to show the relationship of this
|
|||||||
|- My set1 1
|
|- My set1 1
|
||||||
| `- Layer2 2
|
| `- Layer2 2
|
||||||
`- Layer3 1
|
`- Layer3 1
|
||||||
|
```
|
||||||
|
|
||||||
|
#### NOTE.2
|
||||||
|
|
||||||
NOTE.2: The layer index is a number to identify any layer in the
|
The layer index is a number to identify any layer in the sprite, for
|
||||||
sprite, for example:
|
example:
|
||||||
|
|
||||||
|
```
|
||||||
Layer name and hierarchy Layer index
|
Layer name and hierarchy Layer index
|
||||||
-----------------------------------------------
|
-----------------------------------------------
|
||||||
- Background 0
|
- Background 0
|
||||||
@ -314,18 +310,17 @@ NOTE.2: The layer index is a number to identify any layer in the
|
|||||||
|- My set1 3
|
|- My set1 3
|
||||||
| `- Layer2 4
|
| `- Layer2 4
|
||||||
`- Layer3 5
|
`- Layer3 5
|
||||||
|
```
|
||||||
|
|
||||||
|
6. File Format Changes
|
||||||
|
----------------------
|
||||||
|
|
||||||
========================================
|
1. The first change from the first release of the new .ase format,
|
||||||
File Format Changes
|
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,
|
How to read both formats (old and new one)? You should set all
|
||||||
is the new frame duration field. This is because now each frame
|
frames durations to the "speed" field read from the main ASE
|
||||||
can have different duration.
|
header. Then, if you found a frame with the frame-duration
|
||||||
|
field > 0, you should update the duration of the frame with
|
||||||
How to read both formats (old and new one)? You should set all
|
that value.
|
||||||
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.
|
|
@ -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
|
|
@ -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
|
|
@ -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)
|
|
@ -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
|
|
Loading…
x
Reference in New Issue
Block a user