Topic : ATARI ST Picture formats
Author : David Baggett/Jan K⌐upka
Version : atari_gf.hyp 0.01 (17/09/96)
Subject : Documentation/File formats
Nodes : 52
Index Size : 1328
HCP-Version : 3
Compiled on : Atari
@charset : atarist
@lang :
@default :
@help :
@options : -i -s +y +z
@width : 75Cyber Paint Sequence *.SEQ (low resolution only)
This format, while fairly complex, yields excellent compression of
animated images while offering reasonably fast decompression times.
1 wordword = 2 bytes
magic number [$FEDB or $FEDC]
1 wordword = 2 bytes
version number
1 longlong = 4 bytes
number of frames
1 wordword = 2 bytes
speed (high byte is vblanks per frame)
118 bytes reserved
128 bytes total for .SEQ header
for each frame {
1 longlong = 4 bytes
offset to data for this frame, in bytes [basically useless]
}
for each frame {
1 wordword = 2 bytes
type (ignored?)
1 wordword = 2 bytes
resolution [always 0]
16 words palette12 bytes filename [usually " . "]
1 wordword = 2 bytes
color animation limits [not used]
1 wordword = 2 bytes
color animation speed and direction [not used]
1 wordword = 2 bytes
number of color steps [not used]
1 wordword = 2 bytes
x offset for this frame [0 - 319]
1 wordword = 2 bytes
y offset for this frame [0 - 199]
1 wordword = 2 bytes
width of this frame, in pixels (may be 0, see below)
1 wordword = 2 bytes
height of this frame, in pixels (may be 0, see below)
1 byte operation [0 = copy, 1 = exclusive or]
1 byte storage method [0 = uncompressed, 1 = compressed]
1 longlong = 4 bytes
length of data in bytes (if the data is compressed, this
will be the size of the compressed data BEFORE decompression)
60 bytes reserved
128 bytes total for frame header
? bytes data
}
Frames are "delta-compressed," meaning that only the changes from one
frame to the next are stored. On the ST,SEQ files are always full-screen
low resolution animations, so the sequence resulting from expanding all the
data will be n 320 by 200 pixel low resolution screens, where n is
given in the .SEQ header.
Since only the changes from frame to frame are stored, image data for a
frame will rarely be 320x200 (except for the very first frame, which
will always be a full screen). Instead what is stored is the smallest
rectangular region on the screen that contains all the changes from the
previous frame to the current frame. The x offset and y offset in the frame header
determine where the upper left corner of the "change box" lies, and the
width and height specify the box's size.
Additionally, each "change box" is stored in one of five ways. For each
of these, the screen is assumed to have the full-screen image from the last
frame on it.
∙ uncompressed copy: The data for this frame is uncompressed
image data, and is simply copied onto the screen at position (x, y)
specified in the frame header.
∙ uncompressed eor: The data for this frame is exclusive or'ed
with the screen at position (x, y).
∙ compressed copy: The data for this frame must be decompressed
(see below), and then copied onto the screen at position (x, y)
specified
in the frame header.
∙ compressed eor: The data for this frame must be decompressed (see
below), and then exclusive or'ed with the screen RAM at position
(x, y).
∙ null frame: The width and/or height of this frame is 0, so this
frame is the same as the previous frame.
Of the 5 methods above, the one that results in the smallest amount
of data being stored for a particular is used for that frame.
Compression Scheme:
Compression is similar to that employed by Tiny, but is not quite as
space-efficient.
Control wordword = 2 bytes
meanings:
For a given control wordword = 2 bytes
, x:
x < 0 Absolute value specifies the number of unique words to
take from the data section (from 1 to 32767).
x > 0 Specifies the number of times to repeat the next wordword = 2 bytes
taken from the data section (from 1 to 32767).
Note that a control wordword = 2 bytes
of 0 is possible but meaningless.
Format of expanded data:
The expanded data is not simply screen memory bitmap data; instead the
four bitplanes are separated, and the data within each bitplane is
presented vertically instead of horizontally. (This results in better
compression.)
To clarify, data for a full screen would appear in the following order:
bitplane 0, wordword = 2 bytes
0, scanline 0
bitplane 0, wordword = 2 bytes
0, scanline 1
...
bitplane 0, wordword = 2 bytes
0, scanline 199
bitplane 0, wordword = 2 bytes
1, scanline 0
bitplane 0, wordword = 2 bytes
1, scanline 1
...
bitplane 0, wordword = 2 bytes
1, scanline 199
...
bitplane 0, wordword = 2 bytes
79, scanline 199
...
bitplane 1, wordword = 2 bytes
0, scanline 0
...
bitplane 3, wordword = 2 bytes
79, scanline 199
Note however, that the data does not usually refer to an entire screen,
but rather to the smaller "change box," whose size is given in the frame
header.