Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!apollo!rehrauer From: rehrauer@apollo.COM (Steve Rehrauer) Newsgroups: comp.sys.atari.st Subject: Re: Degas file format (again) Summary: DEGAS file format in a (big) nutshell Keywords: more info needed Message-ID: <43b61866.71d0@apollo.COM> Date: 8 Jun 89 17:32:00 GMT References: Reply-To: rehrauer@apollo.COM (Steve Rehrauer) Organization: Apollo Computer, Chelmsford, MA Lines: 140 In article 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!"