🚀 go-pugleaf

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!"