870646c@aucs.UUCP (barry comer) (04/10/88)
Some people were asking about the Degas picture file format, well
here it is:(1 word = 2 bytes)
1 word - Word value is 0=low rez, 1=mid rez, 2=high rez
16 words - colour palette, standard st bios format
16000 words - raw pic data
The following are optional:(added to the normal degas format for
Degas Elite)
4 words - Left animation limit table
This is a table of 4 words values which specify the left limits
of each of the four colour animation channels. The values range
from 0-15, indicating that the corresponding colour palette entry
is the left range of the animation channel's range.
4 words - Right animation limit table
Same as the one for left, but this value should be greater than or
equal to the corresponding left animation limit value for proper
operation.
4 words - Animation channel direction flag
This is a table of 4 word values which specify the cycling
direction for the corresponding animation channel. A value of 0
indicates that the channel shifts its colours to the left,1=
channel is off, and 2=a right shift.
4 words - Animation channel delay
This is a 4 word value table which specifies the speed at which
the colour registers in the animation channel range will be
shifted. The range of permissible values in these variables are 0-
128, indicating the number of 60Hz delay periods between colour
shifts. A value of zero in this table indicates the max speed,
approx. 60 shifts per second; a value of 60 is approx. one shift
per second; a value of 120 is roughly one shift every two seconds.
Well that is the file format for Degas and Degas Elite pics. As I
said the bottom 16 words are optional.
later
Barry
P.S. Could someone that has the RTX multi-tasking prg., please
send me a short review of it.decouty@irisa.UUCP (Bertrand Decouty) (04/13/88)
Could anybody send .IMG (.GEM) and .PIC (for wordplus) file formats?
Thanks a lot.
----- Bertrand DECOUTY @ INRIA-IRISA (Centre de Rennes) -----
+------------------------------+----------------------------------------------+
| IRISA - INRIA | EMAIL : decouty@irisa.fr |
| Campus de Beaulieu | UUCP : {mcvax,inria!}irisa!decouty |
| F-35042 Rennes Cedex | decouty@irisa.UUCP |
| FRANCE | BITNET: DECOUTY@FRCICB71 |
+--------------------------+---+--------------------+-------------------------+
| PHONE : +33 99 36 20 00 | TELEX : 950473 UNIRISA | FAX : +33 99 38 38 32 |
+--------------------------+------------------------+-------------------------+jjoshua@topaz.rutgers.edu (Jon Joshua) (05/26/89)
I am trying to write a Degas viewer program. I've got .PI3 files
down-pat but I can't figure out how .PI{1,2} files are laid out. I
thought that they would be a bit-map like .PI3 files (2 or 4 bits per
pixel, though) but I was wrong. I made a test picture and the resulst
of a hex dump were not what I thought they would be.
Who knows?
JOn.
--
/\ ? ________________
jjoshua@topaz.rutgers.edu \ ____ __ fgu |.signature under|
Anything is possible... \ | | / | orywlut- | construction |
========== gfgsdfsdfsd |________________|
_____________________________OO_____O___hfdhksjdhfksjdfs_______||__________||__jjoshua@topaz.rutgers.edu (Jon Joshua) (05/30/89)
In my original posting I asked for the file format of Degas files. I
should have said that I was doing a viewer program for a PC with VGA.
Knowing that the last 16,000 words is a memory map doesn't help me too
much. I need to know how the words translate into pixels.
Thanks to the many who replied to my original posting. Does anyone
have the details that I need?
JOn.
--
/\ ? ________________
jjoshua@topaz.rutgers.edu \ ____ __ fgu |.signature under|
Anything is possible... \ | | / | orywlut- | construction |
========== gfgsdfsdfsd |________________|
_____________________________OO_____O___hfdhksjdhfksjdfs_______||__________||__jjoshua@topaz.rutgers.edu (Jon Joshua) (05/30/89)
In my original posting I asked for the file format of Degas files. I
should have said that I was doing a viewer program for a PC with VGA.
Knowing that the last 16,000 words is a memory map doesn't help me too
much. I need to know how the words translate into pixels.
Thanks to the many who replied to my original posting. Does anyone
have the details that I need?
JOn.
--
/\ ? ________________
jjoshua@topaz.rrtgers.edu \ ____ __ fgu |.signature under|
Anything is possible... \ | | / | orywlut- | construction |
========== gfgsdfsdfsd |________________|
_____________________________OO_____O___hfdhksjdhfksjdfs_______||__________||__
#!saj@chinet.chi.il.us (Stephen Jacobs) (05/31/89)
J. Joshua needs to know the format of a screen image (DEGAS file) so he can
write a program to isplay DEGAS pictures on VGA. (I'd like a copy when it's
done). The following is my understanding of the consensus of the Abacus
internals book and the Compute Machine Language book. It differs from the way
I read the Compute VDI book's explanation of the screen, but someone said that
that was wrong anyway, in an earlier discussion.
Each word (16 bit word) is associated with a particular bitplane. In 4-color
(medium res) mode,all even numbered words belong to bitplane 0, all odd words
belong to bitplane 1. In 16 color (low res), every 4th word is bitplane 0,
etc. The palette entry is formed by taking 1 bit from each bitplane, in
corresponding positions. In other words, in medium res, the first point gets
a color determined by the first bit of word 0 and the first bit of word 1. The
next point gets a color determined by the second bit of word zero and the
second bit of word 1, etc.
The header of a DEGAS file is, of course, resolution and palette.
The Abacus book has pictures that make the situation almost understandable.
The book itself is precious, and understandable as long as you remember that
it's translated from German.
Steve J.to_stdnet@stag.UUCP (05/31/89)
From: dal@syntel.UUCP (Dale Schumacher) > In my original posting I asked for the file format of Degas files. I > should have said that I was doing a viewer program for a PC with VGA. > Knowing that the last 16,000 words is a memory map doesn't help me too > much. I need to know how the words translate into pixels. Ah, what you want is the memory-image to pixel relationship for the ST's video display. This varies based on the current graphics mode, although it always takes 32000 bytes. I'll describe the format in 8-bit bytes instead of 16-bit words, since you would have a byte-reversal problem if you read words on the PC from a file created on the ST. All modes define pixels starting in the upper left corner of the screen, proceeding horizontally along the scanline, wrapping around the right edge to the next scanline down. Resolution 2, 640x400x1: This uses one bit per pixel, black or white. It's a simple bitmap. The MSB of the first byte represents the upper left pixel. The value of a black pixel (0 or 1) depends on the lowest order bit of the value for the blue gun for color number 0 in the palette. A zero means 0=black and 1=white, but a one means 0=white 1=black. Resolution 1, 640x200x2: This uses two bits per pixel to select a color number from the palette. Each group of 4 bytes defines 16 pixels. The LSB of each color index is in the first pair of bytes, and the MSB is is the second pair of bytes. Thus the MSB of the first byte is the LSB of the color index for the upper left pixel, and the MSB of the third byte of the MSB of the color index for the same pixel. In the diagram below, A and B are the LSB and MSB of the color index for the upper left pixel. [A-------][--------][B-------][--------] byte 0 byte 1 byte 2 byte 3 Example: Data: [01010101][10101010][11111111][00000000] Pixels: 0=10, 1=11, 2=10, 3=11, 4=10, 5=11, 6=10, 7=11, 8=01, 9=00, 10=01, 11=00, 12=01, 13=00, 14=01, 15=00 Resolution 0, 320x200x4: This uses four bits per pixel to select a color number from the palette. Each group of 8 bytes defines 16 pixels. The LSB of each color index is in bytes 0 and 1, and the MSB is in bytes 6 and 7. Thus the MSB of byte 0 is the LSB of the color index for the upper left pixel, and the MSB of byte 6 of the MSB of the color index for the same pixel. In the diagram below, A, B, C, and D are the LSB through MSB of the color index for the upper left pixel. [A-------][--------][B-------][--------] byte 0 byte 1 byte 2 byte 3 [C-------][--------][D-------][--------] byte 4 byte 5 byte 6 byte 7 Example: Data: [01010101][01010101][00110011][00110011] [00001111][00001111][00000000][11111111] Pixels: 0=0000, 1=0001, 2=0010, 3=0011, 4=0100, 5=0101, 6=0110, 7=0111, 8=1000, 9=1001, 10=1010, 11=1011, 12=1100, 13=1101, 14=1110, 15=1111 I hope this clears things up. There's obviously lots of bit twiddling to do to get individual pixels, but it's really not that complex. PS. MSB=Most Significant Bit, LSB=Least Significant Bit :-) -- Dale Schumacher 399 Beacon Ave. (alias: Dalnefre') St. Paul, MN 55104-3527 ...bungia!midgard.mn.org!syntel!dal United States of America "I may be competitive, but I'm never ruthless"
rehrauer@apollo.COM (Steve Rehrauer) (06/09/89)
In article <May.29.22.35.52.1989.10061@topaz.rrs!as.edu> jjoshua@topaz.rutgers.edu (Jon Joshua) writes: > >In my original posting I asked for the file format of Degas files. I >should have said that I was doing a viewer program for a PC with VGA. >Knowing that the last 16,000 words is a memory map doesn't help me too >much. I need to know how the words translate into pixels. > >Thanks to the many who replied to my original posting. Does anyone >have the details that I need? No doubt an hour after I post this, an article written by someone of vastly greater knowledge and clarity will finally reach this node, but, if not, hopefully this will be of use to others as well. The original DEGAS "paintware" supported only one file format, at all three ST graphics resolutions. The successor package, called DEGAS Elite, supports essentially three formats: 1. The "old DEGAS" format (called "uncompressed", because it is). Files written in this format should have extensions of .PI1, .PI2 and .PI3 (for low, medium and high resolutions, respectively). 2. A compressed format, which generally uses less space to store an image but which is slower to read (you gotta decompress it, right?). Files written in this format should have extensions of .PC1, .PC2 and .PC3 (low, medium and high). 3. A "clip-art" format (called "block images" in the manual), which also happens to be the Electronic Arts "IFF" (tm?) format supported on the Amiga. Files written in this format (by DEGAS Elite, at any rate) should have extensions of .BL1, .BL2 and .BL3 (low, medium and high). The IFF format is something of a pain to use, IMHO. Though, it certainly is said to have advantages; talk to some Amigans about that. If you're interested in supporting this format in your viewer, issue #2 of START Magazine described how, and the issue's disk contained source code by Tom Hudson (DEGAS' author) to do this. (Mr. Hudson produced some Really Nifty Things for the ST, but gee -- his 'C' code really sucks. :-) I _think_ the source may've been placed in the public-domain; if so, I can probably mail you a copy. Or, you may still be able to order the mag+disk from: Antic Publishing, 524 Second Street, San Francisco, CA 94107. Price? Dunno. Too much, probably. The uncompressed format is very straight-forward; make the appropriate typedef changes for your 'C' compiler: typedef unsigned int WORD; /* Two bytes */ typedef unsigned char BYTE; /* One byte */ typedef struct { WORD resolution; /* 0=LOW, 1=MED, 2=HI resolution */ WORD palette [16]; /* Values of the ST's 16 color regs. */ BYTE image [32000]; /* The pixel data */ WORD left_anim [4]; /* "Left animation channel" limits */ WORD right_anim [4]; /* "Right animation channel" limits */ WORD anim_direction [4]; /* "Animation channel" directions */ WORD anim_delay [4]; /* "Animation channel" delay */ } RAWDEG_BUF; The "animation channel" stuff is new for DEGAS Elite. I don't believe it will be present in files created by DEGAS -- or if the bytes are actually there, they will be nulls. In any case, don't worry about 'em for your application. Just read the first 32018 bytes of the file. The pixel data is written out exactly as it had laid in memory for an ST screen. ST screens are kinda funky. High res (monochrome) screens are a straight-forward bit-map; the high-order bit of RAWDEG_BUF.image[0] will represent the pixel in the upper lefthand corner of the display. The next- most-significant bit is the pixel to the right of that, and etc. Medium res (4 color) and low res (16 color) screens use interleaved planes of memory. Medium res uses two planes per pixel (2^2 = 4 colors, right?). Low res uses four planes per pixel (2^4 = 16). I'll explain how low res works, and you can guess medium res from that. Basically, each low res pixel uses four bits, which specify what color register to use. 0000 = reg #0, 0011 = reg #3, etc. You'll need to "assemble" your four-bit pixel (which is your index into the color palette) from four WORDs in RAWDEG_BUF.image[]. E.g. (bit15 is most-significant): b15 b14 b13 b12 b11 b10 b09 b08 b07 b06 b05 b04 b03 b02 b01 b00 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | WORD#1 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | WORD#2 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | WORD#3 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 1 | 0 | 1 | 0 | 0 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | WORD#4 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ I'm writing this from (often shoddy) memory, so I MAY be wrong about this next particular snippet (but it'll be quickly obvious if you get really funky-looking pictures the first time through :-)... So anyway, the most-significant bits of the first four words correspond to the pixel in the upper lefthand corner of the display. In this case (and here's where I could be misremembering -- I may have the bit-order reversed), the bits of the pixel are 0-1-0-1, or color reg #5. The next pixel is 1000, or color reg #8. The next is 1001, or reg #9. Etc. If you were reading this stuff on an ST, you'd just dump the 32000 bytes into a buffer and set the display pointer (or perhaps read directly into the current screen buffer). But since you're going to be massaging it on a PeeCee, you get the idea -- you'll be processing 16 pixels at a time, then get the next four words, etc. Color registers on the ST are WORDs, with 3 bits allocated per R/G/B. 9 bits total, a range of 512 colors. The RAWDEG_BUF.palette[] is just a dump of the 16 registers. Each component of R/G/B fits in a 4-bit nybble in the WORD, with the most-significant bit of each nybble being unused. The high-order nybble of the WORD is likewise unused. Gee, it's embarassing to admit that I don't recall whether the layout below is correct, or whether it should be labelled B/G/R. At least green is in the right place :-)... b15 b14 b13 b12 b11 b10 b09 b08 b07 b06 b05 b04 b03 b02 b01 b00 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |XXXXXXXXXXXXXXX|xxx |xxx |xxx | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ RED GREEN BLUE Do you expect to want to be decoding the compressed format? (If your ST artwork is coming from a source who has DEGAS Elite, just ask for uncompressed files!) Else, I can mail you the details on it if you like. It's basically a simple run-length-encoded scheme, compressed in order of scan-lines from top-to-bottom, with each plane compressed separately. And may I humbly suggest that you also add support for NeoChrome files while you're at it? Since the original NeoChrome was free from Atari to ST owners, it tends to be common. I don't recall the pertinent info for them offhand; I _think_ all you'll care about is a 16-WORD palette followed by 32000 BYTEs of pixel data. (NeoChrome only ran in low res.) Cheers, and apologies for taking up so much net.bandwidth! -- >>> "Aaiiyeeeee! Death from above!" <<< | Steve Rehrauer Fone: (508)256-6600 x6168 | Apollo Computer, Inc. ARPA: rehrauer@apollo.com | (A subsidiary of Hewlett-Packard) "Look, Max: 'Pressurized cheese in a can'. Even _WE_ wouldn't eat that!"