|
|
| (47 intermediate revisions by one other user not shown) |
| Line 14: |
Line 14: |
| | Copyright (C) 1988, 1989, 1990, 1991 by David M. Baggett | | Copyright (C) 1988, 1989, 1990, 1991 by David M. Baggett |
| | Additions 2006-2007 Hans Wessels are public domain. | | Additions 2006-2007 Hans Wessels are public domain. |
| − | Additions 2015-2016 Lonny Pursell are public domain. | + | Additions 2015-2017 Lonny Pursell are public domain. |
| | | | |
| | Non-profit redistribution of this document is permitted, provided | | Non-profit redistribution of this document is permitted, provided |
| Line 52: |
Line 52: |
| | [[Canvas file format]] *.CNV *.CPT | | [[Canvas file format]] *.CNV *.CPT |
| | [[COKE file format]] *.TG1 | | [[COKE file format]] *.TG1 |
| | + | [[ColorBurst file format]] *.BST |
| | [[C.O.L.R. Object Editor file format]] *.MUR | | [[C.O.L.R. Object Editor file format]] *.MUR |
| − | [[ComputerEyes Raw Data file format]] *.CE? ? = 1, 2 | + | [[ComputerEyes Raw Data file format]] *.CE? ? = 1, 2, 3 |
| | [[CrackArt file format]] *.CA? ? = 1, 2, 3 | | [[CrackArt file format]] *.CA? ? = 1, 2, 3 |
| | + | [[Cybermate Delta Animation file format]] *.DLT |
| | + | [[Cyber Paint Cell file format]] *.CEL |
| | [[Cyber Paint Sequence file format]] *.SEQ | | [[Cyber Paint Sequence file format]] *.SEQ |
| | + | [[Dali file format]] *.SD? ? = 0, 1, 2 |
| | + | [[Dali Compressed file format]] *.?PK ? = L, M, H |
| | [[DEGAS file format]] *.PI? ? = 1, 2, 3 (4, 5, 6) | | [[DEGAS file format]] *.PI? ? = 1, 2, 3 (4, 5, 6) |
| | [[DEGAS Elite file format]] *.PI? ? = 1, 2, 3 | | [[DEGAS Elite file format]] *.PI? ? = 1, 2, 3 |
| | [[DEGAS Elite Block file format]] *.BL? ? = 1, 2, 3 | | [[DEGAS Elite Block file format]] *.BL? ? = 1, 2, 3 |
| | [[DEGAS Elite Compressed file format]] *.PC? ? = 1, 2, 3 | | [[DEGAS Elite Compressed file format]] *.PC? ? = 1, 2, 3 |
| | + | [[DEGAS Elite Font file format]] *.FNT |
| | [[DEGAS Elite Icon file format]] *.ICN | | [[DEGAS Elite Icon file format]] *.ICN |
| | [[DelmPaint file format]] *.DEL *.DPH | | [[DelmPaint file format]] *.DEL *.DPH |
| | + | [[DeskPic file format]] *.GFB |
| | [[Doodle file format]] *.DOO | | [[Doodle file format]] *.DOO |
| − | [[DuneGraph file format]] *.DGU *.DGC | + | [[DUO file format]] *.DU? ? = 1, 2, O |
| | + | [[DuneGraph file format]] *.DG1 *.DC1 |
| | [[EggPaint file format]] *.TRP | | [[EggPaint file format]] *.TRP |
| | + | [[EZ-Art Professional file format]] *.EZA |
| | [[FuckPaint file format]] *.PI4 *.PI9 | | [[FuckPaint file format]] *.PI4 *.PI9 |
| | + | [[Funny Paint file format]] *.FUN |
| | + | [[GDOS Font file format]] *.FNT |
| | [[GEM Bit Image file format]] *.IMG | | [[GEM Bit Image file format]] *.IMG |
| | + | [[GEM Metafile file format]] *.GEM |
| | + | [[GFA Artist file format]] *.ART |
| | + | [[GFA Raytrace file format]] *.SA? *.SC? *.SU? ? = L, H |
| | [[GodPaint file format]] *.GOD | | [[GodPaint file format]] *.GOD |
| | [[HighresMedium file format]] *.HRM | | [[HighresMedium file format]] *.HRM |
| | [[IFF file format]] *.IFF | | [[IFF file format]] *.IFF |
| | + | [[ImageLab file format]] *.B&W *.B_W |
| | [[Imagic Film/Picture file format]] *.IC? ? = 1, 2, 3 | | [[Imagic Film/Picture file format]] *.IC? ? = 1, 2, 3 |
| | + | [[IMG Scan file format]] *.RWL *.RWH *.RAW |
| | [[IndyPaint file format]] *.TRU | | [[IndyPaint file format]] *.TRU |
| | [[InShape file format]] *.IIM | | [[InShape file format]] *.IIM |
| | + | [[Lexicor Film file format]] *.FLM |
| | [[MacPaint file format]] *.MAC | | [[MacPaint file format]] *.MAC |
| | [[MegaPaint file format]] *.BLD | | [[MegaPaint file format]] *.BLD |
| Line 78: |
Line 95: |
| | [[NEOchrome Animation file format]] *.ANI | | [[NEOchrome Animation file format]] *.ANI |
| | [[Overscan Interlaced file format]] *.PCI | | [[Overscan Interlaced file format]] *.PCI |
| − | [[Photochrome file format]] *.PCS | + | [[Pablo Paint file format]] *.PPP *.PA3 |
| − | [[Picture Packer file format]] *.PP1? ? = 1, 2, 3 | + | [[PaintPro ST/PlusPaint ST]] *.PIC |
| | + | [[PaintShop file format]] *.PSC *.DA4 |
| | + | [[Paintworks file format]] *.CL? *.PG? *.SC? ? = 0, 1, 2 |
| | + | [[PhotoChrome file format]] *.PCS |
| | + | [[Picture Packer file format]] *.PP? ? = 1, 2, 3 |
| | + | [[Picworks file format]] *.CP3 |
| | [[PixArt file format]] *.PIX | | [[PixArt file format]] *.PIX |
| | + | [[PL4 file format]] *.PL4 |
| | + | [[Print-Technik Raw Data file format]] *.HIR |
| | + | [[Public Painter file format]] *.CMP |
| | [[QuantumPaint file format]] *.PBX | | [[QuantumPaint file format]] *.PBX |
| − | [[RGB Intermediate Format]] *.RGB | + | [[Rag-D file format]] *.RAG |
| | + | [[Rembrandt file format]] *.TCP |
| | + | [[RGB Intermediate file format]] *.RGB |
| | + | [[Signum! file format]] *.IMC |
| | [[Spectrum 512 file format]] *.SPU | | [[Spectrum 512 file format]] *.SPU |
| | [[Spectrum 512 Compressed file format]] *.SPC | | [[Spectrum 512 Compressed file format]] *.SPC |
| − | [[Spectrum 512 Extended]] *.SPX | + | [[Spectrum 512 Enhanced file format]] *.SPU |
| | + | [[Spectrum 512 Extended file format]] *.SPX |
| | [[Spectrum 512 Smooshed file format]] *.SPS | | [[Spectrum 512 Smooshed file format]] *.SPS |
| | + | [[Spooky Sprites file format]] *.TRE *.TRP |
| | [[STAD file format]] *.PAC | | [[STAD file format]] *.PAC |
| | [[STOS Memory Bank file format]] *.MBK | | [[STOS Memory Bank file format]] *.MBK |
| | + | [[Synthetic Arts file format]] *.SRT |
| | [[Tiny file format]] *.TN? ? = 1, 2, 3, Y, (4, 5, 6) | | [[Tiny file format]] *.TN? ? = 1, 2, 3, Y, (4, 5, 6) |
| | + | [[TmS Cranach file format]] *.ESM |
| | + | [[TruePaint Animation file format]] *.TPA |
| | [[TruePaint/Prism Paint file format]] *.TPI *.PNT | | [[TruePaint/Prism Paint file format]] *.TPI *.PNT |
| | + | [[Video Master file format]] *.FLM *.VID *.VSQ |
| | + | [[Warp9 Font file format]] *.FNT |
| | + | [[ZZ_ROUGH file format]] *.RGH |
| | | | |
| | [[PackBits Compression Algorithm]] | | [[PackBits Compression Algorithm]] |
| Line 123: |
Line 159: |
| | palette entry, since a few programs store special | | palette entry, since a few programs store special |
| | information there (most notably Art Studio). | | information there (most notably Art Studio). |
| − |
| |
| − |
| |
| − | The Formats
| |
| − | -----------
| |
| − |
| |
| − |
| |
| − | <CarckArt> *.CA1 (low resolution)
| |
| − | *.CA2 (medium resolution)
| |
| − | *.CA3 (high resolution)
| |
| − |
| |
| − | 1 word 'CA' crackart magic
| |
| − | 1 byte compression: 00 = uncompressed, 01 = compressed
| |
| − | 1 byte resolution: 00 = low res, 01 = medium res, 02 = high res
| |
| − | ?? words palette
| |
| − | For low res pictures there are 16 palette entries
| |
| − | For med res pictures there are 4 palette entries
| |
| − | For high res pictures there are 0 palette entries
| |
| − | ?? bytes Picture data:
| |
| − | For uncompressed pictures 32000 bytes follow
| |
| − | For compressed pictures the compressed data follows
| |
| − |
| |
| − | -----------
| |
| − | < 32057 bytes total
| |
| − |
| |
| − | CrackArt data compression:
| |
| − | 1 byte Escape character
| |
| − | 1 byte Delta: initially the 32000 screen memory are
| |
| − | filled with the delta byte
| |
| − | 1 word Offset: offset between two packed bytes;
| |
| − | Offset is added to the current byte position
| |
| − | to calculate the next byte position. When the
| |
| − | next byte position is greater 32000, the next
| |
| − | byte position is the first position of screen
| |
| − | memory not written to
| |
| − | if Offset = 0, the whole screen if filled with
| |
| − | the delta byte, no packed bytes follow
| |
| − |
| |
| − | 1 byte Cmd: Command byte
| |
| − | Cmd <> Escape character: Cmd = one literal byte
| |
| − | Cmd = Escape charater:
| |
| − | read 1 control byte
| |
| − | 0: read one byte, n, and one byte, b;
| |
| − | repeat b (n+1) times
| |
| − | 1: read one word, n, and one byte, b;
| |
| − | repeat b (n+1) times
| |
| − | 2: read one byte, if zero: stop else read
| |
| − | one extra byte and to make word n:
| |
| − | repeat Delta (n+1) times
| |
| − | Escape character: output one escape charater
| |
| − | else: read one byte, b;
| |
| − | repeat b cmd times
| |
| − | Decompression stops when Escape 2,0 is found or 32000 bytes have been written
| |
| − |
| |
| − |
| |
| − | <ArtDirector> *.ART
| |
| − |
| |
| − | 32000 bytes Picture data
| |
| − | 8x16 words 8 palettes
| |
| − | 8 bytes 8 palette flags, the first pallete with a nonzero flag is used
| |
| − | 248 bytes ?? possibly animation infromation
| |
| − | -----------
| |
| − | 32512 bytes total
| |
| − |
| |
| − | <Tiny> *.TNY (any resolution)
| |
| − | *.TN1 (low resolution)
| |
| − | *.TN2 (medium resolution)
| |
| − | *.TN3 (high resolution)
| |
| − |
| |
| − | Several people have reported sightings of mutated Tiny pictures that
| |
| − | do not follow the standard format, so let's be careful out there. What
| |
| − | is described here is the format that David Mumper's original
| |
| − | TNYSTUFF.PRG produces. The TN4 extension has been found on animated low
| |
| − | resolution files. One can assume the same person(s) will also use TN5 and
| |
| − | TN6 for extensions for animated medium and high resolution.
| |
| − |
| |
| − | 1 byte resolution (same as NEO, but +3 indicates rotation
| |
| − | information also follows)
| |
| − |
| |
| − | If resolution > 2 {
| |
| − | 1 byte left and right color animation limits. High 4 bits
| |
| − | hold left (start) limit; low 4 bits hold right (end) limit
| |
| − | 1 byte direction and speed of color animation (negative value
| |
| − | indicates left, positive indicates right, absolute value
| |
| − | is delay in 1/60's of a second.
| |
| − | 1 word color rotation duration (number of iterations)
| |
| − | }
| |
| − |
| |
| − | 16 words palette
| |
| − | 1 word number of control bytes
| |
| − | 1 word number of data words
| |
| − | 3-10667 bytes control bytes
| |
| − | 1-16000 words data words
| |
| − | -------------
| |
| − | 42-32044 bytes total
| |
| − |
| |
| − | Control byte meanings:
| |
| − |
| |
| − | For a given control byte, x:
| |
| − |
| |
| − | x < 0 Copy -x of unique words to take from the data section
| |
| − | (from 1 to 128)
| |
| − | x = 0 1 word is taken from the control section which specifies
| |
| − | the number of times to repeat the next data word (from
| |
| − | 128 to 32767)
| |
| − | x = 1 1 word is taken from the control section which specifies
| |
| − | the number of unique words to be taken from the data
| |
| − | section (from 128 - 32767)
| |
| − | x > 1 Specifies the number of times to repeat the next word
| |
| − | taken from the data section (from 2 to 127)
| |
| − |
| |
| − | Format of expanded data:
| |
| − |
| |
| − | The expanded data is not simply screen memory bitmap data; instead, the
| |
| − | data is divided into four sets of vertical columns. (This results in
| |
| − | better compression.) A column consists of one specific word taken
| |
| − | from each scan line, going from top to bottom. For example, column 1
| |
| − | consists of word 1 on scanline 1 followed by word 1 on scanline 2, etc.,
| |
| − | followed by word 1 on scanline 200.
| |
| − | The columns appear in the following order:
| |
| − |
| |
| − | 1st set contains columns 1, 5, 9, 13, ..., 69, 73, 77 in order
| |
| − | 2nd set contains columns 2, 6, 10, 14, ..., 70, 74, 78 in order
| |
| − | 3rd set contains columns 3, 7, 11, 15, ..., 71, 75, 79 in order
| |
| − | 4th set contains columns 4, 8, 12, 16, ..., 72, 76, 80 in order
| |
| − |
| |
| − | Note that Tiny partitions the screen this way regardless of resolution; i.e.,
| |
| − | these aren't bitplanes. For example, medium resolution only has two bitplanes,
| |
| − | but Tiny still divides medium resolution pictures into four parts.
| |
| − |
| |
| − |
| |
| − | <Spectrum 512> *.SPU
| |
| − |
| |
| − | 80 words first scan line of picture (unused) -- should be zeroes
| |
| − | 15920 words picture data (screen memory) for scan lines 1 through 199
| |
| − | 9552 words 3 palettes for each scan line (the top scan line is
| |
| − | not included because Spectrum 512 can't display it)
| |
| − | -----------
| |
| − | 51104 bytes total
| |
| − |
| |
| − | Note that the Spectrum 512 mode's three palette changes per scan
| |
| − | line allow more colors on the screen than normally possible, but a
| |
| − | tremendous amount of CPU time is required to maintain the image.
| |
| − |
| |
| − | The Spectrum format specifies a palette of 48 colors for each scan line.
| |
| − | To decode a Spectrum picture, one must be know which of these 48 colors
| |
| − | are in effect for a given horizontal pixel position.
| |
| − |
| |
| − | Given an x-coordinate (from 0 to 319) and a color index (from 0 to 15),
| |
| − | the following C function will return the proper index into the Spectrum
| |
| − | palette (from 0 to 47):
| |
| − |
| |
| − | /*
| |
| − | * Given an x-coordinate and a color index, returns the corresponding
| |
| − | * Spectrum palette index.
| |
| − | *
| |
| − | * by Steve Belczyk; placed in the public domain December, 1990.
| |
| − | */
| |
| − | int
| |
| − | FindIndex(x, c)
| |
| − | int x, c;
| |
| − | {
| |
| − | int x1;
| |
| − |
| |
| − | x1 = 10 * c;
| |
| − |
| |
| − | if (1 & c) /* If c is odd */
| |
| − | x1 = x1 - 5;
| |
| − | else /* If c is even */
| |
| − | x1 = x1 + 1;
| |
| − |
| |
| − | if (x >= x1 && x < x1 + 160)
| |
| − | c = c + 16;
| |
| − | else if (x >= x1 + 160)
| |
| − | c = c + 32;
| |
| − |
| |
| − | return c;
| |
| − | }
| |
| − |
| |
| − |
| |
| − | <Spectrum 512 (Compressed)> *.SPC
| |
| − |
| |
| − | 1 word flag word [$5350 or "SP"]
| |
| − | 1 word reserved for future use [always 0]
| |
| − | 1 long length of data bit map
| |
| − | 1 long length of color bit map
| |
| − | <= 32092 bytes compressed data bit map
| |
| − | <= 17910 bytes compressed color bit map
| |
| − | --------------
| |
| − | <= 50014 bytes total
| |
| − |
| |
| − | Data compression:
| |
| − |
| |
| − | Compression is via a modified run length encoding (RLE) scheme,
| |
| − | similar to DEGAS compressed and Tiny. The data map is stored as a
| |
| − | sequence of records. Each record consists of a header byte followed by
| |
| − | one or more data bytes. The meaning of the header byte is as follows:
| |
| − |
| |
| − | For a given header byte, x:
| |
| − |
| |
| − | 0 <= x <= 127 Use the next x + 1 bytes literally (no repetition)
| |
| − | -128 <= x <= -1 Use the next byte -x + 2 times
| |
| − |
| |
| − | The data appears in the following order:
| |
| − |
| |
| − | 1. Picture data, bit plane 0, scan lines 1 - 199
| |
| − | 2. Picture data, bit plane 1, scan lines 1 - 199
| |
| − | 3. Picture data, bit plane 2, scan lines 1 - 199
| |
| − | 4. Picture data, bit plane 3, scan lines 1 - 199
| |
| − |
| |
| − | Decompression of data ends when 31840 data bytes have been used.
| |
| − |
| |
| − | Color map compression:
| |
| − |
| |
| − | Each 16-word palette is compressed separately. There are three
| |
| − | palettes for each scan line (597 total). The color map is stored as a
| |
| − | sequence of records. Each record starts with a 1-word bit vector which
| |
| − | specifies which of the 16 palette entries are included in the data
| |
| − | following the bit vector (1 = included, 0 = not included). If a palette
| |
| − | entry is not included, it is assumed to be zero (black). The least
| |
| − | significant bit of the bit vector refers to palette entry zero, while the
| |
| − | most significant bit refers to palette entry 15. Bit 15 must be zero,
| |
| − | since Spectrum 512 does not use palette entry 15. Bit 0 should also be
| |
| − | zero, since Spectrum 512 always makes the background color black.
| |
| − | The words specifying the values for the palette entries indicated in
| |
| − | the bit vector follow the bit vector itself, in order (0 - 15).
| |
| − |
| |
| − | NOTE: Regarding Spectrum pictures, Shamus McBride reports the following:
| |
| − |
| |
| − | "... [The Picture Formats List] says bit 15 of the color map vector
| |
| − | must be zero. I've encountered quite a few files where [bit 15] is
| |
| − | set (with no associated palette entry)..."
| |
| − |
| |
| − |
| |
| − | <Spectrum 512 (Smooshed), or Anispec, see below> *.SPS
| |
| − |
| |
| − | This format compresses Spectrum 512 pictures better than the standard
| |
| − | method. There are at least two programs that support this format, SPSLIDEX
| |
| − | and ANISPEC, although the two seem to differ slightly in their interpretation
| |
| − | of the format.
| |
| − | One point of interest: Shamus McBride deciphered this format without an ST!
| |
| − |
| |
| − | 1 word 5350 (hex) ("SP")
| |
| − | 1 word 0 (reserved for future use)
| |
| − | 1 long length of data bit map
| |
| − | 1 long length of color bit map
| |
| − | <= 32092 bytes compressed data bit map
| |
| − | <= 17910 bytes compressed color bit map
| |
| − | ----------
| |
| − | < 50014 bytes total
| |
| − |
| |
| − | Data compression:
| |
| − |
| |
| − | Compression is via a modified run length encoding (RLE) scheme,
| |
| − | similar to that used in Spectrum Compressed (*.SPC) pictures.
| |
| − |
| |
| − | The data map is stored as a sequence of records. Each record consists of a
| |
| − | header byte followed by one or more data bytes. The meaning of the header
| |
| − | byte is as follows:
| |
| − |
| |
| − | For a given header byte, x (unsigned):
| |
| − |
| |
| − | 0 <= x <= 127 Use the next byte x + 3 times
| |
| − | 128 <= x <= 255 Use the next x - 128 + 1 bytes literally
| |
| − | (no repetition)
| |
| − |
| |
| − | There are two kinds of *.SPS files. The type is defined by the least significant
| |
| − | bit of the last byte in the color bit map.
| |
| − |
| |
| − | If the bit is set the data appears in the same order as *.SPC files:
| |
| − |
| |
| − | 1. Picture data, bit plane 0, scan lines 1 - 199
| |
| − | 2. Picture data, bit plane 1, scan lines 1 - 199
| |
| − | 3. Picture data, bit plane 2, scan lines 1 - 199
| |
| − | 4. Picture data, bit plane 3, scan lines 1 - 199
| |
| − |
| |
| − | If the bit is not set the data is encoded as byte wide vertical strips:
| |
| − |
| |
| − | Picture data, bit plane 0, scan line 1, MSB.
| |
| − | Picture data, bit plane 0, scan line 2, MSB.
| |
| − | Picture data, bit plane 0, scan line 3, MSB.
| |
| − | . . .
| |
| − | Picture data, bit plane 0, scan line 199, MSB.
| |
| − | Picture data, bit plane 0, scan line 1, LSB.
| |
| − | Picture data, bit plane 0, scan line 2, LSB.
| |
| − | . . .
| |
| − | Picture data, bit plane 0, scan line 199, LSB.
| |
| − | Picture data, bit plane 1, scan line 1, MSB.
| |
| − | . . .
| |
| − | Picture data, bit plane 3, scan line 198, LSB
| |
| − | Picture data, bit plane 3, scan line 199, LSB.
| |
| − |
| |
| − | A for loop to process that data would look like
| |
| − |
| |
| − | for (plane = 0; plane < 4; plane++)
| |
| − | for (x = 0; x < 320; x += 8)
| |
| − | for (y = 1; y < 200; y++)
| |
| − | for (x1 = 0; x1 < 8; x1++)
| |
| − | image[y, x + x1] = ...
| |
| − |
| |
| − | Color map compression:
| |
| − |
| |
| − | Color map compression is similar to *.SPC color map compression, but
| |
| − | the map is compressed as a string of bits, rather than words. There are
| |
| − | 597 records (one for each palette). Each record is composed of a 14-bit
| |
| − | header followed by a number of 9-bit palette entries. The 14-bit header
| |
| − | specifies which palette entries follow (1 = included, 0 = not included).
| |
| − | The most significant bit of the header refers to palette entry 1, while
| |
| − | the least significant bit refers to palette 14. Palette entries 0 and 15
| |
| − | are forced to black (zero). Each palette entry is encoded as "rrrgggbbb".
| |
| − |
| |
| − | The format of the palette is described above in the section on uncompressed
| |
| − | Spectrum pictures (*.SPU).
| |
| − |
| |
| − | <Spectrum 512 (Anispec)> *.SPS
| |
| − | Format for animated Spectrum pictures.
| |
| − |
| |
| − | 1 word 5353 (hex) ("SS")
| |
| − | 30 bytes unknown header bytes
| |
| − | 51104 bytes uncompressed spectrum picture (see SPU format)
| |
| − | ?? bytes animation data (unknown format)
| |
| − |
| |
| − |
| |
| − | <Spectrum 512 Extended> *.SPX
| |
| − | SPX files are extended Spectrum files with more than 200 lines in the picture,
| |
| − | designed by Gizmo of Electronic Images. With a SPX createor like SPXCRT14.PRG
| |
| − | multiple spectrumpictures can be attachted to become one big .SPX file. There
| |
| − | are two known versions of the format. Version 2 files of the format can be
| |
| − | packed as a whole (including the header) with either Ice 2.10 or Atomik 3.5.
| |
| − |
| |
| − | 3 bytes 'SPX', SPX magic header
| |
| − | 1 byte version (01 or 02)
| |
| − | 1 byte graphics compression flag, 0 = unpacked
| |
| − | 1 byte palette compression flag, 0 = unpacked
| |
| − | 1 byte number of 32000 byte screens
| |
| − | 3 bytes reserved
| |
| − | ?? bytes NULL terminated author string
| |
| − | ?? bytes NULL terminated description string
| |
| − | 4 bytes size of (packed) graphics data in bytes
| |
| − | 4 bytes size of (packed) palette data in bytes
| |
| − | ?? bytes (packed) graphics data
| |
| − | ?? bytes (packed) palette data
| |
| − |
| |
| − | The number of lines in the picture can be calculated by deviding the size of
| |
| − | the unpacked graphics data by 160. The unpacked SPX picture can be treated as a
| |
| − | Spectrum screen with more than 200 lines.
| |
| − |
| |
| − | In version 1 when a compression flag is set the data is packed with Ice 2.10.
| |
| − |
| |
| − | In version 2 a special packer is used, graphics and palettes are packed in one chunk.
| |
| − | 4 bytes depacked size
| |
| − | 4 bytes packed size
| |
| − | Like the Ice packer data is packed from end of file to start. The depakcer starts
| |
| − | to read data from packed data start+packed size and to write data to
| |
| − | depacked data start+depacked size. A long is read form packed data into a bitbuffer,
| |
| − | when the bitbuffer is empty it is refilled with a new long from the packed file.
| |
| − | With getbits(n) the n most significat bytes are read from the bitbuffer.
| |
| − | while(bytes read<depacked size)
| |
| − | getbits(1)
| |
| − | 0 : literals
| |
| − | len = getbits(4*(getbits(2)+1))
| |
| − | read len bytes with getbits(8) and write them to the destination
| |
| − | if(len<>$ffff) do a ptr_len
| |
| − | 1 : ptr_len
| |
| − | ptr = getbits(4*(getbits(2)+1))
| |
| − | len = getbits(4*(getbits(2)+1))
| |
| − | copy len+3 bytes from ptr
| |
| − | Note: after a literal there is always a ptr_len except when len was $ffff.
| |
| − |
| |
| − |
| |
| − | <PhotoChrome> *.PCS (low resolution only)
| |
| − |
| |
| − | 1 word 0x0140 (hex) x-resolution (always 320)
| |
| − | 1 word 0x00C8 (hex) y-resolution (always 200)
| |
| − | 1 byte 00 = single screen mode
| |
| − | nonzero value's = alternating screen mode,
| |
| − | bit 0 (0x01) not set: second screen data is xor'ed with first screen
| |
| − | bit 1 (0x02) not set: second color palette is xor'ed with first
| |
| − | 1 byte bit 0 (0x01) set: 50 Hz mode, when not set 60 Hz mode
| |
| − | ?? bytes compressed screen data
| |
| − | ?? bytes compressed palette
| |
| − | ?? bytes compressed second screen data (in case of alternating screens)
| |
| − | ?? bytes compressed second palette
| |
| − | -------------
| |
| − | > 18 bytes total
| |
| − |
| |
| − | Screen compression scheme:
| |
| − | 1 word total number of control bytes that follow
| |
| − | 1 control byte x
| |
| − | x < 0 : copy -x literal bytes (1 - 128)
| |
| − | x = 0 : next word specifies the number of times the following byte
| |
| − | has to be copied (0-65535)
| |
| − | x = 1 : next word specifies the number of bytes to be copied (0-65535)
| |
| − | x > 1 : repeat the next byte x times (2-127)
| |
| − |
| |
| − | The 4 bitplanes are separated, first 8000 bytes of the first bitplane, then 8000 bytes
| |
| − | for the second, 8000 bytes for the third and 8000 bytes for the fourth; a total of 32000 bytes.
| |
| − |
| |
| − | Palette compression scheme:
| |
| − | the palette compression scheme is the same as the screen compression but it works with
| |
| − | 16 bit words
| |
| − | 1 word total number of control bytes that follow
| |
| − | 1 control byte x
| |
| − | x < 0 : copy -x literal words (1 - 128)
| |
| − | x = 0 : next word specifies the number of times the following word
| |
| − | has to be copied (0-65535)
| |
| − | x = 1 : next word specifies the number of words to be copied (0-65535)
| |
| − | x > 1 : repeat the next word x times (2-127)
| |
| − |
| |
| − | In total 9616 palette entries are stored. 200 scanlines with 3 palettes
| |
| − | (48 colors) each, plus one final palette (16 colors). PhotoChrome files
| |
| − | with a few extra entries have been found. The first scanline usually
| |
| − | contains no data.
| |
| − |
| |
| − | /*
| |
| − | * Given an x-coordinate and a color index, returns the corresponding
| |
| − | * Photochrome palette index.
| |
| − | *
| |
| − | * by Hans Wessels; placed in the public domain januari, 2008.
| |
| − | */
| |
| − | int find_pcs_index(int x, int c)
| |
| − | {
| |
| − | int x1=4*c;
| |
| − | int index = c;
| |
| − | if(x>=x1)
| |
| − | {
| |
| − | index+=16;
| |
| − | }
| |
| − | if((x>=(x1+64+12)) && (c<14))
| |
| − | {
| |
| − | index+=16;
| |
| − | }
| |
| − | if((x>=(132+16)) && (c==14))
| |
| − | {
| |
| − | index+=16;
| |
| − | }
| |
| − | if((x>=(132+20)) && (c==15))
| |
| − | {
| |
| − | index+=16;
| |
| − | }
| |
| − | x1=10*c;
| |
| − | if((c&1)==1)
| |
| − | {
| |
| − | x1-=6;
| |
| − | }
| |
| − | if((x>=(176+x1)) && (c<14))
| |
| − | {
| |
| − | index+=16;
| |
| − | }
| |
| − | return index;
| |
| − | }
| |
| − |
| |
| − | <QuantumPaint> *.PBX (low and medium resolution)
| |
| − |
| |
| − | 3 bytes 0
| |
| − | 1 byte mode, 0x00 = 128 color low resolution pciture,
| |
| − | 0x01 = 32 color medium resolution picture,
| |
| − | 0x80 = 512 color picture low resolution picture
| |
| − | 0x81 = 4096 color picture low resolution picture
| |
| − | 1 word 0x8001 = compressed
| |
| − | Quantumpaint v2.00 sets it to 0x8000 for uncompressed files
| |
| − | Quantumpaint v1.00 seems to use 0x0000 for lowras and 0x0333
| |
| − | for medium res bytes. The PBX viewer only tests for 0x8001.
| |
| − | 122 bytes ??
| |
| − | total 128 header bytes
| |
| − | ?? bytes palette data;
| |
| − | for uncompressed normal pictures 8 pallete datasets follow:
| |
| − | 16 words: 16 palettes
| |
| − | 1 word: number of the first line this pallet is used
| |
| − | 1 word: 0 the palette is not active, else this pallete is active
| |
| − | 1 word: first color of color cycle
| |
| − | 1 word: last color of color cycle
| |
| − | 1 word: cycle speed, number of vbl's between steps, 0 = fastest
| |
| − | 1 word: 0: no cycling, 1 cycle right, 0xffff cycle left
| |
| − | 2 word: ?? should be zero
| |
| − | __
| |
| − | 48 bytes per palette
| |
| − | The first palette should always be active and start on line 0
| |
| − | ___
| |
| − | 384 bytes palette data for low (128 color) and medium (32 color) pictures
| |
| − | for uncompressed 512 color pictures 6400 words (32 colors per scanline)
| |
| − | for uncompressed 4096 color pictures 12800 words (32 colors per scanline,
| |
| − | 2 palette sets for alternating screens, two 6400 word blocks)
| |
| − | ?? bytes screen data, for uncompressed pictures this is 32000 bytes for all modes
| |
| − | --------
| |
| − | > 128 bytes total
| |
| − |
| |
| − | Compression scheme
| |
| − | Palette and screen data are compressed into one block using packbits compression.
| |
| − | The expanded screen data is not simply screen memory bitmap data; instead, the
| |
| − | data is divided into four sets of vertical columns. (This results in
| |
| − | better compression.) A column consists of one specific word taken
| |
| − | from each scan line, going from top to bottom. For example, column 1
| |
| − | consists of word 1 on scanline 1 followed by word 1 on scanline 2, etc.,
| |
| − | followed by word 1 on scanline 200.
| |
| − | The columns appear in the following order:
| |
| − |
| |
| − | 1st set contains columns 1, 5, 9, 13, ..., 69, 73, 77 in order
| |
| − | 2nd set contains columns 2, 6, 10, 14, ..., 70, 74, 78 in order
| |
| − | 3rd set contains columns 3, 7, 11, 15, ..., 71, 75, 79 in order
| |
| − | 4th set contains columns 4, 8, 12, 16, ..., 72, 76, 80 in order
| |
| − | This colmn ordering is just the same as in the Tiny format.
| |
| − | for medium res it is the same only with two stes for the two medium res bitplanes.
| |
| − |
| |
| − | /*
| |
| − | * Given an x-coordinate and a color index, returns the corresponding
| |
| − | * QuantumPaint palette index.
| |
| − | *
| |
| − | * by Hans Wessels; placed in the public domain januari, 2008.
| |
| − | */
| |
| − | int find_pbx_index(int x, int c)
| |
| − | {
| |
| − | int x1 = 10 * c;
| |
| − | if (1 & c)
| |
| − | { /* If c is odd */
| |
| − | x1 = x1 - 5;
| |
| − | }
| |
| − | else
| |
| − | { /* If c is even */
| |
| − | x1 = x1 + 1;
| |
| − | }
| |
| − | if(c>7)
| |
| − | {
| |
| − | x1+=12;
| |
| − | }
| |
| − | if(x>=(x1+75))
| |
| − | {
| |
| − | c = c + 16;
| |
| − | }
| |
| − | return c;
| |
| − | }
| |
| − |
| |
| − |
| |
| − | <Art Director> *.ART (low resolution only)
| |
| − |
| |
| − | 16000 words picture data (screen memory)
| |
| − | 16 words palette
| |
| − | 7 * 16 words 7 more palettes for animation
| |
| − | 8 * 1 byte display time for palettes, use first palette with non zero display time
| |
| − | 248 bytes unknown
| |
| − | -------------
| |
| − | 32512 bytes total
| |
| − |
| |
| − |
| |
| − | <Cyber Paint Sequence> *.SEQ (low resolution only)
| |
| − |
| |
| − | This format, while fairly complex, yields excellent compression of animated
| |
| − | images while offering reasonably fast decompression times.
| |
| − |
| |
| − | 1 word magic number [$FEDB or $FEDC]
| |
| − | 1 word version number
| |
| − | 1 long number of frames
| |
| − | 1 word speed (high byte is vblanks per frame)
| |
| − | 118 bytes reserved
| |
| − | ---------
| |
| − | 128 bytes total for .SEQ header
| |
| − |
| |
| − | for each frame {
| |
| − | 1 word type (ignored?)
| |
| − | 1 word resolution [always 0]
| |
| − | 16 words palette
| |
| − | 12 bytes filename [usually " . "]
| |
| − | 1 word color animation limits [not used]
| |
| − | 1 word color animation speed and direction [not used]
| |
| − | 1 word number of color steps [not used]
| |
| − | 1 word x offset for this frame [0 - 319]
| |
| − | 1 word y offset for this frame [0 - 199]
| |
| − | 1 word width of this frame, in pixels (may be 0, see below)
| |
| − | 1 word 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 long 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.
| |
| − |
| |
| − | o 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.
| |
| − |
| |
| − | o uncompressed eor: The data for this frame is exclusive or'ed with the
| |
| − | screen at position (x, y).
| |
| − |
| |
| − | o 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.
| |
| − |
| |
| − | o 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).
| |
| − |
| |
| − | o 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 word meanings:
| |
| − |
| |
| − | For a given control word, 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 word
| |
| − | taken from the data section (from 1 to 32767).
| |
| − |
| |
| − | Note that a control word 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, word 0, scanline 0
| |
| − | bitplane 0, word 0, scanline 1
| |
| − | ...
| |
| − | bitplane 0, word 0, scanline 199
| |
| − | bitplane 0, word 1, scanline 0
| |
| − | bitplane 0, word 1, scanline 1
| |
| − | ...
| |
| − | bitplane 0, word 1, scanline 199
| |
| − | ...
| |
| − | bitplane 0, word 79, scanline 199
| |
| − | bitplane 1, word 0, scanline 0
| |
| − | ...
| |
| − | bitplane 3, word 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.
| |
| − |
| |
| − |
| |
| − | <Animatic Film> *.FLM (low resolution only)
| |
| − |
| |
| − | 1 word number of frames
| |
| − | 16 words palette
| |
| − | 1 word speed (0 - 99; value is 99 - # vblanks to delay between frames)
| |
| − | 1 word direction (0 = forwards, 1 = backwards)
| |
| − | 1 word end action (what to do after the last frame)
| |
| − | 0 = pause, then repeat from beginning
| |
| − | 1 = immediately repeat from beginning
| |
| − | 2 = reverse (change direction)
| |
| − | 1 word width of film in pixels
| |
| − | 1 word height of film in pixels
| |
| − | 1 word Animatic version number (major) [< 2]
| |
| − | 1 word Animatic version number (minor)
| |
| − | 1 long magic number 27182818 (hex)
| |
| − | 3 longs reserved for expansion (should be all zeros)
| |
| − | --------
| |
| − | 32 words total for header
| |
| − |
| |
| − | ? words image data (words of screen memory) for each frame, in order
| |
| − |
| |
| − |
| |
| − | <Animaster Sprite Bank> *.ASB (low resolution only)
| |
| − |
| |
| − | 1 word number of frames - 1
| |
| − | 1 word frame length including 6 byte frame header
| |
| − | 1 byte maximum width, in pixels
| |
| − | 1 byte maximum height, in pixels
| |
| − | 16 words palette
| |
| − | --------
| |
| − | 38 bytes total for header
| |
| − |
| |
| − | For each frame {
| |
| − | 1 word width of this frame (in pixels) - 1
| |
| − | 1 word height of this frame (in pixels) - 1
| |
| − | 1 word number of color planes [always 4]
| |
| − | ? words image data (words of screen memory)
| |
| − | }
| |
| − |
| |
| − |
| |
| − | <STOS> *.MBK
| |
| − |
| |
| − | 9 words ?
| |
| − | 1 long $19861987 (magic number?)
| |
| − | 1 long offset from this long to header for low resolution
| |
| − | parameter block (if past end of file, no low res frames)
| |
| − | 1 long offset from this long to header for med resolution
| |
| − | parameter block (if past end of file, no med res frames)
| |
| − | 1 long offset from this long to header for high resolution
| |
| − | parameter block (if past end of file, no high res frames)
| |
| − | 1 word number of low resolution frames
| |
| − | 1 word number of medium resolution frames
| |
| − | 1 word number of high resolution frames
| |
| − |
| |
| − | For each frame {
| |
| − | 1 long offset to data (probably only used internally by STOS)
| |
| − | 1 byte width in words (multiply by 16 to get width in pixels)
| |
| − | 1 byte height in pixels
| |
| − | 1 byte X hotspot location
| |
| − | 1 byte Y hotspot location
| |
| − | }
| |
| − |
| |
| − | (The format implies other stuff could be here.)
| |
| − |
| |
| − | 1 long ["PALT" $50414C54]
| |
| − | 16 words palette
| |
| − |
| |
| − | ? words of data for each frame, in the order mentioned in the
| |
| − | header. Monoplanar mask data follows image data for each
| |
| − | frame.
| |
| − | ----------
| |
| − | ? words total
| |
| − |
| |
| − | The frames often seem to be in semi-random order, not necessarily in
| |
| − | the order they are to be animated.
| |
| − |
| |
| − |
| |
| − | <GEM Bit Image> *.IMG
| |
| − |
| |
| − | 1 word version number of image file [1]
| |
| − | 1 word length of header in words [usually 8]
| |
| − | 1 word number of color planes [1 for monochrome]
| |
| − | 1 word pattern length in bytes [1-8, usually 2 for screen images]
| |
| − | 1 word pixel width in microns (1/1000 mm, 25400 microns per inch)
| |
| − | 1 word pixel height in microns
| |
| − | 1 word line width in pixels
| |
| − | 1 word number of lines
| |
| − | -------
| |
| − | ? words header length defined in 2nd word of header
| |
| − |
| |
| − | ? bytes data
| |
| − |
| |
| − | NOTES: If the image is a color image (planes > 1), the planes are stored
| |
| − | separately starting with plane 0. There is, however, no standard way of
| |
| − | storing the color palette. Some programs may save the palette in separate
| |
| − | files, some may extend the header. For this reason, you should never
| |
| − | assume the header is 8 words long, always get the header length from the
| |
| − | 2nd word of the header. Also, the line width in the 7th word is the number
| |
| − | of pixels in a line. Since the data is encoded in byte-wide packets, the
| |
| − | actual unpacked line width is always a multiple of 8, and may be 1-7 pixels
| |
| − | longer than the length specified in the header.
| |
| − |
| |
| − | For each byte x in the data section,
| |
| − |
| |
| − | x = 0 Pattern/scanline run.
| |
| − | Read the next byte, n (unsigned).
| |
| − |
| |
| − | If n > 0 then:
| |
| − | Read a number of bytes equal to the "pattern
| |
| − | length" word in the header. Repeat this
| |
| − | pattern n times.
| |
| − |
| |
| − | If n = 0 then:
| |
| − | Scanline run. Data for the next scanline
| |
| − | is to be used multiple times. Read the
| |
| − | following record:
| |
| − |
| |
| − | 1 byte flag byte [$FF]
| |
| − | 1 byte number of times to use
| |
| − | next scanline data
| |
| − |
| |
| − | The data for the next scanline follows,
| |
| − | compressed normally.
| |
| − |
| |
| − | x = 80 (hex) Uncompressed bit string. The next byte
| |
| − | determines the number of bytes to use
| |
| − | literally. The literal data bytes follow.
| |
| − |
| |
| − | otherwise Solid run. The value of x determines
| |
| − | what to draw. The high bit specifies whether
| |
| − | the pixels are set or cleared. A 1 indicates
| |
| − | a byte-run using $FF, a 0 indicates a byte-run
| |
| − | using $00. The low 7 bits, taken as an unsigned
| |
| − | quantity, specify the length of the run in bytes.
| |
| − |
| |
| − |
| |
| − | <STAD> *.PAC (high resolution only)
| |
| − |
| |
| − | 4 bytes "pM86" (vertically packed) or "pM85" (horizontally packed)
| |
| − | 1 byte id byte
| |
| − | 1 byte pack byte (most frequently occurring byte in bitmap)
| |
| − | 1 byte "special" byte
| |
| − | -------
| |
| − | 7 bytes total for header
| |
| − |
| |
| − | ? bytes data
| |
| − |
| |
| − | The data is encoded as follows. For each byte x in the data section:
| |
| − |
| |
| − | x = id byte Read one more byte, n. Use pack byte
| |
| − | n + 1 times.
| |
| − | x = "special" byte Read two more bytes, d, and n (in order).
| |
| − | Use byte d n + 1 times.
| |
| − | otherwise Use byte x literally.
| |
| − |
| |
| − |
| |
| − | <Imagic Film/Picture> *.IC1 (low resolution)
| |
| − | *.IC2 (medium resolution)
| |
| − | *.IC3 (high resolution)
| |
| − |
| |
| − | 4 bytes "IMDC"
| |
| − | 1 word resolution (0 = low res, 1 = medium res, 2 = high res)
| |
| − | 16 words palette
| |
| − | 1 word date (GEMDOS format)
| |
| − | 1 word time (GEMDOS format)
| |
| − | 8 bytes name of base picture file (for delta compression), or zeroes
| |
| − | 1 word length of data (?)
| |
| − | 1 long registration number
| |
| − | 8 bytes reserved
| |
| − | 1 byte compressed? (0 = no, 1 = yes)
| |
| − |
| |
| − | If compressed {
| |
| − | 1 byte delta-compressed? (-1 = no, > -1 = yes)
| |
| − | 1 byte ?
| |
| − | 1 byte escape byte
| |
| − | }
| |
| − | -------
| |
| − | 65 bytes total for header (68 bytes if compressed)
| |
| − |
| |
| − | ? bytes data
| |
| − |
| |
| − | Compressed data may be either stand-alone or delta-compressed (relative
| |
| − | to the base picture named in the header). Delta compression involves
| |
| − | storing only how the picture differs from the base picture (i.e., only
| |
| − | portions of the screen that have changed are stored). This is used to
| |
| − | to encode animated sequences efficiently.
| |
| − |
| |
| − | Compressed data, stand-alone:
| |
| − |
| |
| − | For each byte x in the data section:
| |
| − |
| |
| − | x = escape byte Read one more byte, n. (n is unsigned).
| |
| − |
| |
| − | If n >= 2, use the next byte n times.
| |
| − | If n = 1, keep reading bytes until a
| |
| − | byte k not equal to 1 is encountered.
| |
| − | Then read the next byte d.
| |
| − | If the number of 1 bytes encountered is o,
| |
| − | use d (256 * o + k) times. I.e.,
| |
| − |
| |
| − | if (n == 1) {
| |
| − | o = 0;
| |
| − | while (n == 1) {
| |
| − | o++;
| |
| − | n = next byte;
| |
| − | }
| |
| − |
| |
| − | k = n;
| |
| − | d = next byte;
| |
| − |
| |
| − | Use d (256 * o + k) times.
| |
| − | }
| |
| − | else {
| |
| − | d = next byte;
| |
| − | Use d (n) times.
| |
| − | }
| |
| − |
| |
| − | x != escape byte Use x literally.
| |
| − |
| |
| − | Compressed data, delta compressed:
| |
| − |
| |
| − | For each byte x in the data section:
| |
| − |
| |
| − | x = escape byte Read one more byte, n. (n is unsigned).
| |
| − |
| |
| − | If n >= 3, use the next byte n times.
| |
| − | If n = 1, do the same as for n = 1 in
| |
| − | stand-alone compression (above).
| |
| − | If n = 2, then set n = next byte.
| |
| − | If n = 0, end of picture.
| |
| − | If n >= 2, take n bytes from base
| |
| − | picture.
| |
| − | If n = 1, do the same as for n = 1
| |
| − | in stand-alone compression (above),
| |
| − | but take (256 * o + k) bytes from
| |
| − | base picture.
| |
| − |
| |
| − | x != escape byte Use x literally.
| |
| − |
| |
| − |
| |
| − | <IFF Format> *.IFF
| |
| − |
| |
| − | 4 bytes "FORM" (FORM chunk ID)
| |
| − | 1 long length of file that follows
| |
| − | 4 bytes "ILBM" (InterLeaved BitMap file ID)
| |
| − |
| |
| − | 4 bytes "BMHD" (BitMap HeaDer chunk ID)
| |
| − | 1 long length of chunk [20]
| |
| − | 20 bytes 1 word = image width in pixels
| |
| − | 1 word = image height in lines
| |
| − | 1 word = image x-offset [usually 0]
| |
| − | 1 word = image y-offset [usually 0]
| |
| − | 1 byte = # bitplanes
| |
| − | 1 byte = mask (0=no, 1=impl., 2=transparent, 3=lasso)
| |
| − | 1 byte = uncompressed [0], packbits [1], vertical RLE [2]
| |
| − | 1 byte = unused [0]
| |
| − | 1 word = transparent color (for mask=2)
| |
| − | 1 byte = x-aspect [5=640x200, 10=320x200/640x400, 20=320x400]
| |
| − | 1 byte = y-aspect [11]
| |
| − | 1 word = page width (usually the same as image width)
| |
| − | 1 word = page height (usually the same as image height)
| |
| − |
| |
| − | 4 bytes "CMAP" (ColorMAP chunk ID)
| |
| − | 1 long length of chunk [3*n where n is the # colors]
| |
| − | 3n bytes 3 bytes per RGB color. Each color value is a byte
| |
| − | and the actual color value is left-justified in the
| |
| − | byte such that the most significant bit of the value
| |
| − | is the MSB of the byte. (ie. a color value of 15 ($0F)
| |
| − | is stored as $F0) The bytes are stored in R,G,B order.
| |
| − |
| |
| − | 4 bytes "CRNG" (Color RaNGe chunk ID)
| |
| − | 1 long length of chunk [8]
| |
| − | 8 bytes 1 word = reserved [0]
| |
| − | 1 word = animation speed (16384 = 60 steps per second)
| |
| − | 1 word = active [1] or inactive [0]
| |
| − | 1 byte = left/lower color animation limit
| |
| − | 1 byte = right/upper color animation limit
| |
| − |
| |
| − | 4 bytes "CAMG" (Commodore AMiGa viewport mode chunk ID)
| |
| − | 1 long length of chunk [4]
| |
| − | 1 long viewport mode bits:
| |
| − | bit 2 = interlaced
| |
| − | bit 7 = half-bright
| |
| − | bit 11 = HAM
| |
| − | bit 15 = high res
| |
| − |
| |
| − | 4 bytes "BODY" (BODY chunk ID)
| |
| − | 1 long length of chunk [# bytes of image data that follow]
| |
| − | ? bytes actual image data
| |
| − |
| |
| − | NOTES: Some of these chunks may not be present in every IFF file, and may
| |
| − | not be in this order. You should always look for the ID bytes to find a
| |
| − | certain chunk. All chunk IDs are followed by a long value that tells the
| |
| − | size of the chunk (note that "ILBM" is not a chunk ID). This is the number of
| |
| − | bytes that FOLLOW the 4 ID bytes and size longword. The exception to this is
| |
| − | the FORM chunk. The size longword that follows the FORM ID is the size of the
| |
| − | remainder of the file. The FORM chunk must always be the first chunk in an
| |
| − | IFF file.
| |
| − |
| |
| − | The R,G,B ranges of AMIGA and ST are different (AMIGA 0...15, ST 0...7),
| |
| − | as is the maximum number of bitplanes (AMIGA: 5, ST: 4).
| |
| − |
| |
| − | Format of body data
| |
| − |
| |
| − | An expanded picture is simply a bitmap. The most common packing method is
| |
| − | PackBits (see below), and is identical to MacPaint and DEGAS Elite compressed.
| |
| − |
| |
| − | The (decompressed) body data appears in the following order:
| |
| − |
| |
| − | line 1 plane 0 ... line 1 plane 1 ... ... line 1 plane m
| |
| − | [line 1 mask (if appropriate)]
| |
| − | line 2 plane 0 ... line 2 plane 1 ... ... line 2 plane m
| |
| − | [line 2 mask (if appropriate)]
| |
| − | ...
| |
| − | line x plane 0 ... line x plane 1 ... ... line x plane m
| |
| − | [line x mask (if appropriate)]
| |
| − |
| |
| − | The FORM chunk identifies the type of data:
| |
| − |
| |
| − | "ILBM" = interleaved bit map
| |
| − | "8SVX" = 8-bit sample voice
| |
| − | "SMUS" = simple music score
| |
| − | "FTXT" = formatted text (Amiga)
| |
| − |
| |
| − | The ST version of DPAINT always uses the vertical RLE packing format in the body data.
| |
| − | Within the BODY chunk there is one VDAT chunk per bit plane (four in total). Every VDAT chunk
| |
| − | is laid out in columns, similar to the Tiny format. Only the compression scheme is slightly
| |
| − | different, command 0, and 1 are flipped, and extra count words store in data list.
| |
| − | 4 bytes 'VDAT' vertical bitplane data
| |
| − | 4 bytes length of cunk
| |
| − | ?? bytes compressed data
| |
| − |
| |
| − | Data compression format:
| |
| − | 2 bytes cmd_cnt command bytes count - 2
| |
| − | ? bytes cmd_cnt - 2 command bytes.
| |
| − | ? words data words
| |
| − |
| |
| − | Note that the number of commands is 2 more than actual commands, and that the data
| |
| − | words may start on an odd address if the number of command bytes are odd.
| |
| − |
| |
| − | while(cmd_cnt>2)
| |
| − | 1 byte cmd 0: read one data word as count
| |
| − | output count literal words from data words.
| |
| − | 1: read one command word as count, then one data word as data
| |
| − | output data count times
| |
| − | <0: -cmd is count, output count words from data words
| |
| − | >2: cmd is count, read one data word as data
| |
| − | output data count times
| |
| − |
| |
| − |
| |
| − | <HighresMedium> *.HRM
| |
| − |
| |
| − | This format is found in only one demo: "HighResMode" by Paradox. The
| |
| − | pictures are interlaced in medium resolution with 35 colors per line.
| |
| − | The files are packed with Ice. The unpacked format is as follows:
| |
| − | 64000 bytes screen data, 160 bytes per scanline, 400 lines
| |
| − | 28000 bytes palette data, 70 bytes per line
| |
| − | -----
| |
| − | 96000 bytes
| |
| − |
| |
| − | /*
| |
| − | * Given an x-coordinate and a color index, returns the corresponding
| |
| − | * HighResMedium palette index.
| |
| − | *
| |
| − | * by Hans Wessels; placed in the public domain januari, 2008.
| |
| − | */
| |
| − | int find_hrm_index(int x, int c)
| |
| − | {
| |
| − | x+=80;
| |
| − | if(c==0)
| |
| − | {
| |
| − | return -1+4*(int)((x+0)/80);
| |
| − | }
| |
| − | else if(c==1)
| |
| − | {
| |
| − | return 4*(int)((x-8)/80);
| |
| − | }
| |
| − | else if(c==2)
| |
| − | {
| |
| − | return 1+4*(int)((x-40)/80);
| |
| − | }
| |
| − | return 2+4*(int)((x-48)/80);
| |
| − | }
| |
| − |
| |
| − |
| |
| − | <Overscan Interlaced> *.PCI
| |
| − |
| |
| − | This format is found in only one demo: "Tobias Richter Fullscreen
| |
| − | Slideshow". The pictures are in an interlaced overscan format and
| |
| − | use a separate pallette per scanline (16 colors). The resolution of
| |
| − | the screendata is 352 x 278 pixels, with 176 words per line.
| |
| − | The files are packed with the Ice. The unpacked format is as follows:
| |
| − | 48928 bytes screen data first screen
| |
| − | 48928 bytes screen data second screen
| |
| − | 8896 bytes color data first screen
| |
| − | 8896 bytes color data second screen
| |
| − | ------
| |
| − | 115648 bytes total
| |
| − |
| |
| − | The screen data is stored in 4 seperate bitplane blocks: first all data
| |
| − | of bitplane 0, then all data of bitplane 1, then the data of bitplane 2
| |
| − | and last the data of bitplane 3.
| |
| − |
| |
| − |
| |
| − | <Picture Packer> *.PP1 (low resolution)
| |
| − | *.PP2 (medium resolution)
| |
| − | *.PP3 (high resolution)
| |
| − |
| |
| − | This is a STOS packed screen without the STOS MBK header in front of the
| |
| − | data. Although the STOS screen format has a flag for the resolution this
| |
| − | flag is set to medium resolution for all *.PP? files. The only correct
| |
| − | resolution info is in the extension. A realy brainded format.
| |
| − |
| |
| − |
| |
| − | <MacPaint> *.MAC
| |
| − |
| |
| − | 1 long version number [0=ignore header, 2=header valid]
| |
| − | 38 * 8 bytes 8x8 brush/fill patterns. Each byte is a pattern row,
| |
| − | and the bytes map the pattern rows top to bottom. The
| |
| − | patterns are stored in the order they appear at the bottom
| |
| − | of the MacPaint screen top to bottom, left to right.
| |
| − | 204 bytes unused
| |
| − | -------------
| |
| − | 512 bytes total for header
| |
| − |
| |
| − | < 51200 bytes compressed bitmap data
| |
| − | -------------
| |
| − | < 51712 bytes total
| |
| − |
| |
| − | NOTE: The version number is actually a flag to MacPaint to indicate if
| |
| − | the brush/fill patterns are present in the file. If the version is 0,
| |
| − | the default patterns are used. Therefore you can simply save a MacPaint
| |
| − | file by writing a blank header (512 $00 bytes), followed by the packed
| |
| − | image data.
| |
| − |
| |
| − | Bitmap compression:
| |
| − |
| |
| − | The bitmap data is for a 576 pixel by 720 pixel monochrome image.
| |
| − | The packing method is PackBits (see below). There are 72 bytes per
| |
| − | scan line. Each bit represents one pixel; 0 = white, 1 = black.
| |
| − |
| |
| − |
| |
| − | <RGB Intermediate Format> *.RGB (low resolution only)
| |
| − |
| |
| − | This format was invented by Lars Michael to facilitate conversions between
| |
| − | standard ST picture formats and higher resolution formats like GIF and IFF.
| |
| − | It supports 12 bits of color resolution by keeping the red, green and blue
| |
| − | components in separate bit planes.
| |
| − |
| |
| − | 1 word resolution (ignored)
| |
| − | 16 word palette (ignored)
| |
| − | 16000 words red plane (screen memory)
| |
| − | 1 word resolution (ignored)
| |
| − | 16 word palette (ignored)
| |
| − | 16000 words green plane (screen memory)
| |
| − | 1 word resolution (ignored)
| |
| − | 16 word palette (ignored)
| |
| − | 16000 words blue plane (screen memory)
| |
| − | ------------
| |
| − | 96102 bytes total
| |
| − |
| |
| − | The format was derived by concatenating three DEGAS .PI1 files together --
| |
| − | one for each color gun. The RGB value for a pixel is constructed by looking
| |
| − | at the appropriate pixel in the red plane, green plane, and blue plane. The
| |
| − | bitplanes are in standard ST low resolution screen RAM format, but where pixel
| |
| − | values in screen RAM refer to palette entries (0 through 15), pixel values
| |
| − | here correspond to absolute R, G, and B values. The red, green, and blue
| |
| − | components for each pixel range from 0 to 15 (4 bits), yielding a total of
| |
| − | 12 bits of color information per pixel. Not coincidentally, this is exactly
| |
| − | the format of ST palette entries (although on ST's without the extended
| |
| − | palette only the lower 3 bits of each color component are used).
| |
| − |
| |
| − | You can view a single bit plane on a standard ST by splitting the .RGB file
| |
| − | into its three DEGAS .PI1 components and setting the palette to successively
| |
| − | brighter shades of gray.
| |
| − |
| |
| − |
| |
| − | <TruePaint> *.TPI
| |
| − | <PrismPaint> *.PNT
| |
| − |
| |
| − | 1 long $504e5400 'PNT ' TruePaint Magic
| |
| − | 1 word $0100 ???? file version
| |
| − | 1 word palette_size Might be there in true color
| |
| − | 1 word x_size
| |
| − | 1 word y_size
| |
| − | 1 word bits_per_pixel
| |
| − | 1 word compression, $0000 uncompressed, $0001 prsimpaint compressed
| |
| − | 1 long picture_data_size = ((x_size+15)&0xffff0)*y_size*bits_per_pixel/8
| |
| − | (uncompressed)
| |
| − | 108 bytes $0
| |
| − | ---------
| |
| − | 128 bytes total for header
| |
| − |
| |
| − | 3*palette_size words Palette data, RGB, values 0..1000. The colors are in
| |
| − | VDI order
| |
| − |
| |
| − | picture_data_size bytes Interleaved bitplanes for bits_per_pixel<16, a 16 bit
| |
| − | word per pixel for 16-bit pictures, RRRRrGGGGGgBBBBBb.
| |
| − | The line length is a multiple of 16 pixels for all bit depths
| |
| − | The prismpaint compressed format uses the packbits compression algorithm. For every
| |
| − | scanline the bitplanes are compressed seperately. The falcon high color resolution
| |
| − | (16 bit) is compressed as if there were 16 bitplanes, which there are not.
| |
| − |
| |
| | | | |
| | ------------------------------------------------------------------------- | | ------------------------------------------------------------------------- |
