home *** CD-ROM | disk | FTP | other *** search
/ The World of Computer Software / World_Of_Computer_Software-02-387-Vol-3of3.iso / c / cinemker.zip / SNIPSPEC.DOC < prev   
Text File  |  1991-08-21  |  6KB  |  130 lines

  1.  
  2.                 ComputerEyes "Snip" File Format
  3.                 ===============================
  4.  
  5. This document describes the format of the data contained in a
  6. ComputerEyes "Snip" (.SNP) file.  A Snip file contains a
  7. moving image, or snip.
  8.  
  9. The bytes in the file that make up word and longword values
  10. are all stored in low-to-high sequential order.
  11.  
  12. Unlike other moving image file formats, the Snip format is
  13. optimized for performance, with a slight sacrifice in
  14. flexibility.  This allows moving images to be played with good
  15. performance on most computers with VGA graphics capability, not
  16. just high-powered, expensive computers.
  17.  
  18. All Byte Offsets are relative to the beginning of the file.
  19.  
  20. There is one 16-byte File Header at the beginning of the file:
  21.  
  22.  Byte    Number
  23. Offset  of Bytes  Name    Description
  24. -------------------------------------------------------------
  25.   0        2      VER     Software Version Number
  26.   2        2      NFRM    Number of frames in Snip
  27.   4        2      HRES    Horizontal Resolution
  28.   6        2      VRES    Vertical Resolution
  29.   8        2              Reserved
  30.   10       2      DELAY   Delay Time between frames
  31.   12       2              Reserved
  32.   14       2              Reserved
  33.  
  34. DELAY is a value that represents the approximate time between
  35. frames, expressed in 1/18-second ticks.  For example, if DELAY =
  36. 9, there is 9/18 or one-half second between frames.
  37.  
  38. The File Header is followed by the color palette table.  The
  39. color palette is organized as 256 3-byte triplets: red, then
  40. green, then blue.  The RGB values range from 0 to 63.  This
  41. palette contains all 256 colors, although the frame data consists
  42. of palette pointers whose values range only from 64 to 255.
  43.  
  44.  Byte    Number
  45. Offset  of Bytes  Name    Description
  46. -------------------------------------------------------------
  47.   16       768    PAL     Color palette
  48.  
  49. Following the palette is a table of (NFRM+1) longword offsets to
  50. the beginning of each frame's data.  There is one extra offset to
  51. allow Snip file readers to calculate the size of the last frame.
  52. That is, Size(N) = FROFF(N+1) - FROFF(N).
  53.  
  54.  Byte    Number
  55. Offset  of Bytes  Name    Description
  56. -------------------------------------------------------------
  57.  784   4*(NFRM+1) FROFF   Table of longword offsets to the
  58.                           start of each frame
  59.  
  60. Finally comes NFRM frames of image data, as described below:
  61.  
  62. The IMAGE data is encoded in a simple yet effective manner to
  63. achieve reasonably high image compression, while allowing moving
  64. images to be played back without a lot of software overhead
  65. (which would affect performance) or image compression hardware
  66. (which would affect one's budget).  The compression scheme is as
  67. follows:
  68.  
  69. Images are stored starting in the upper left corner, proceeding
  70. left to right for HRES pixels, then top to bottom for VRES lines.
  71. The Snip file reader must maintain a counter that corresponds to
  72. the current pixel location (we'll call it COUNT).  If an image
  73. data value is 64 or greater, it is interpreted simply as a
  74. palette pointer and written to the screen at the current pixel
  75. location (COUNT), which is incremented.  If an image data value
  76. is less than 64 (but greater than 0), it is interpreted instead
  77. as the number of pixels to skip; specifically, the image data
  78. value is added to COUNT.  An image data value of 0 is interpreted
  79. as an end-of-frame flag.
  80.  
  81. COUNT should be set to 0 at the beginning of a frame.  It is
  82. allowed to wrap around at the end of lines, so that COUNT would
  83. proceed from 0 to HRES*VRES as the frame is read.  It is up to
  84. the Snip file reader to map COUNT to the physical display address
  85. as the frame is read.
  86.  
  87. Typically, in a Snip, the first frame is considered all new so
  88. that there would be exactly HRES*VRES bytes in the first frame,
  89. whose values all range from 64 to 255.  Then, in subsequent
  90. frames, relatively few pixels require changing from one frame to
  91. the next, requiring perhaps a few hundred bytes per frame.
  92.  
  93. The following is an example of the data in a typical frame:
  94.  
  95.         Hex     Dec     Interpretation
  96.         ---     ---     ---------------------------------------
  97.         9C      156     Upper left pixel = 156
  98.         C2      194     Next pixel to right = 194
  99.         04      4       Make no change to next 4 pixels
  100.         83      131     Seventh pixel from top left = 131
  101.         3F      63      Skip next 63 pixels
  102.         3F      63      And another 63 pixels
  103.         21      33      And another 33 pixels
  104.         F1      241     Next pixel = 241
  105.         |
  106.         |
  107.         |
  108.         00      0       Frame done
  109.  
  110. Note that this compression is NOT done on a line-by-line basis.
  111. Thus, if you were working on the first line with an HRES of 128
  112. pixels, COUNT were 120, and you encountered the following
  113. sequence:
  114.  
  115.         Hex     Dec     Interpretation
  116.         ---     ---     ---------------------------------------
  117.         |
  118.         14      20      Skip 20 pixels
  119.         A3      163     Next pixel = 163
  120.         |
  121.  
  122. the 163 would be displayed in the 12th pixel from the left on the
  123. second line.
  124.  
  125. Within a Snip, the frame offset table FROFF can safely be ignored
  126. if the Snip file reader is simply reading frames sequentially and
  127. displaying them.  FROFF can be useful for applications that, for
  128. example, play Snips backwards or edit Snips.
  129.  
  130.