•  Back 
  •  %Main 
  •  Index 
  •  Tree View 
  •  Cross references 
  •  Help page 
  •  Show info about hypertext 
  •  View a new file 
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        palette
12 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.