johnmac@fawlty.towers.oz (John MacLean) (08/01/90)
I wrote to Matt D at Apple about standardizing 3200 color file formats,
given that I have already come accross 3 (2 of these have aux-type variations),
and that there is apparently already another.
He would like to see these graphics within APF format,
which sounds to me like a good idea.
He also asked me to put forward a proposal;
so here is what I think I will suggest:
1) For a uncompressed file format, I will suggest:
- use a new file type (ie: $00C1, auxtype $????) and store the data in
"Brooks Format" ($7D00 bytes of pixel data followed by
200x32 bytes of palette data - with palettes in reverse order)
2) For a compressed File Format, I will suggest:
- use APF (ie: $00C0, auxtype $0002).
- put the pixel data in the "MAIN" Information Block.
- and either:
a) define a new Information Block called "MULTIPAL":
Length: LongInt
Kind: String "MULTIPAL"
NumPalettes: Integer (should be the same as NumScanLines in MAIN)
PaletteArray: [0..NumPalettes-1] of reversed palettes
b) just use the existing Information Block "PALETTES",
and any software reading such a file should reverse the palettes.
If there are NumScanLine palettes then this identifies a graphic.
I prefer a), because the identification of this block ensures it is a
multiple palette graphic (1 palette per scanline), and software does
not need to reverse the palettes (all formats store the palettes in
reverse order).
Would any one like to comment on this before I make such a recomendation.
Please pass this on to others who might have an interest.
John MacLean.
--
This net: johnmac@fawlty.towers.oz.au Phone: +61 2 427 2999
That net: uunet!fawlty.towers.oz.au!johnmac Fax: +61 2 427 7072
Snail: Tower Technology, Unit D 31-33 Sirius Rd, Home: +61 2 960 1453
Lane Cove, NSW 2066, Australia.toddpw@tybalt.caltech.edu (Todd P. Whitesel) (08/02/90)
About the palette reversals (essentially, GET RID OF THEM!):
I feel very strongly that a standard format should NOT reverse or convolute
the palette data in ANY way whatsoever, in spite of the 'all the existing
formats do it' reasoning.
Apparently, the line number order of the palettes themselves isn't linear,
either -- supposedly the order of the palettes as they are stored in the file
is reversed for each set of 16 lines... BLEARGH! You aren't REALLY thinking
of spec'ing THAT?!?
If you are creating a standard it should be as simple and elegant as possible
when people want to figure out what goes where. Leave the conversion to
efficient (but bizarre) internal data structures up to the reader/displayer.
While I'm hot and hack-righteous, let me issue an open challenge to anyone:
convince me why the palettes have to be stored in a convoluted manner in the
first place. I will be perfectly happy to talk assembly.
Better yet, somebody send me some working source, and I'll patch it to display
'common sense' { array [0..scanlines-1] of array [0..15] of mastercolorvalue }
ordered palettes.
Todd Whitesel
toddpw @ tybalt.caltech.edurussotto@eng.umd.edu (Matthew T. Russotto) (08/03/90)
In article <1990Aug1.231338.7751@laguna.ccsf.caltech.edu> toddpw@tybalt.caltech.edu (Todd P. Whitesel) writes: >About the palette reversals (essentially, GET RID OF THEM!): > >I feel very strongly that a standard format should NOT reverse or convolute >the palette data in ANY way whatsoever, in spite of the 'all the existing >formats do it' reasoning. > >Apparently, the line number order of the palettes themselves isn't linear, >either -- supposedly the order of the palettes as they are stored in the file >is reversed for each set of 16 lines... BLEARGH! You aren't REALLY thinking >of spec'ing THAT?!? This is NOT true for any of the straight-3200 files (bitmap data followed by pallettes) I've seen. (After hearing about it, I tried reversing in my program, and the results were clearly incorrect.) The colors in the palette, however, were reversed. (And there is that stoopid LSB-MSB thing, but I guess that's the processors fault :-) ) >If you are creating a standard it should be as simple and elegant as possible >when people want to figure out what goes where. Leave the conversion to >efficient (but bizarre) internal data structures up to the reader/displayer. -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu ][, ][+, ///, ///+, //e, //c, IIGS, //c+ --- Any questions? Hey! Bush has NO LIPS!
rond@pro-grouch.cts.com (Ron Dippold) (08/04/90)
In-Reply-To: message from toddpw@tybalt.caltech.edu > While I'm hot and hack-righteous, let me issue an open challenge to > anyone: convince me why the palettes have to be stored in a convoluted > manner in the first place. I will be perfectly happy to talk assembly. I don't see where I'll need to do that. I have to build the code anyway to change the pallettes on the fly, which involves creating code that looks sort of like: TOP: lda $c005 LONGX ldx #$9ffe txs pea 1234 pea 2345 ... ; push rest of 8 pallettes ; wait till scan line is in those 8 pallettes pea 3534 pea 1233 ... ; push rest of other 8 pallettes. ^^^ ; do this until we reach the bottom of the screen ; then we have lots of time to do other stuff ; during the VBL. This give plenty of time for ; animation. JMP top The point being that you have to build the code in advance to switch the pallettes, so that when you are building it, you can load the pallettes any damn way you please. UUCP: crash!pro-grouch!rond ARPA: crash!pro-grouch!rond@nosc.mil INET: rond@pro-grouch.cts.com
johnmac@fawlty.towers.oz (John MacLean) (08/06/90)
In article <1990Aug1.231338.7751@laguna.ccsf.caltech.edu> toddpw@tybalt.caltech.edu (Todd P. Whitesel) writes: >About the palette reversals (essentially, GET RID OF THEM!): >I feel very strongly that a standard format should NOT reverse or convolute >the palette data in ANY way whatsoever, in spite of the 'all the existing >formats do it' reasoning. > >Todd Whitesel >toddpw @ tybalt.caltech.edu Todd, you'll be happy to know that palettes are not reversed in all the existing formats as I was led to believe. I only recievied my first external source of 3200 pics a few days ago, and they were totally incompatible with the pics I had created. It is also NOT true that the palettes themselves are reversed. This all comes from the fact that most source going around uses palette $F for scanline 0, $E for palette 1 etc, etc. Most source also puts the last color in each palette into memory first. The palette data in all formats is: +$00 Palette for scanline 0: color0 color1 color2 ..... color F +$20 Palette for scanline 1: .......... ............ +$1E0 Palette for scanline 199: color0 ..... color F Just as I and everyone else would have initially hoped. As for the standard form in APF. This seems to imply that we might as well use the 'PALETTE' chunk. Any APF file with a MAIN and a PALETTE with the number of scanlines == the number of palettes is a multi palette picture. I'll stick with Brooks format for uncompressed - but change the filetype. Again - pass this on for anyone interested. John MacLean. -- This net: johnmac@fawlty.towers.oz.au Phone: +61 2 427 2999 That net: uunet!fawlty.towers.oz.au!johnmac Fax: +61 2 427 7072 Snail: Tower Technology, Unit D 31-33 Sirius Rd, Home: +61 2 960 1453 Lane Cove, NSW 2066, Australia.
russotto@eng.umd.edu (Matthew T. Russotto) (08/09/90)
In article <434@fawlty.towers.oz> johnmac@fawlty.ips.oz (John MacLean) writes: > >Todd, > you'll be happy to know that palettes are not reversed in all the >existing formats as I was led to believe. >I only recievied my first external source of 3200 pics a few days ago, and >they were totally incompatible with the pics I had created. > >It is also NOT true that the palettes themselves are reversed. > >This all comes from the fact that most source going around uses palette $F >for scanline 0, $E for palette 1 etc, etc. >Most source also puts the last color in each palette into memory first. > >The palette data in all formats is: > >+$00 Palette for scanline 0: color0 color1 color2 ..... color F >+$20 Palette for scanline 1: .......... >............ >+$1E0 Palette for scanline 199: color0 ..... color F Unless our terminology is different, this does not match my experience with the 3200 pictures (including the three that seem to have started it, Almadan, Fashion, and Brick). I call color0 the color to be displayed when the bit pattern '0000' appears in the bitmap data. I've found that color to be last in the pallettes. I've found the 3200 palettes to be the reverse of the palettes in standard $C1 type pictures. -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu ][, ][+, ///, ///+, //e, //c, IIGS, //c+ --- Any questions? Hey! Bush has NO LIPS!
toddpw@tybalt.caltech.edu (Todd P. Whitesel) (08/09/90)
russotto@eng.umd.edu (Matthew T. Russotto) writes: >Unless our terminology is different, this does not match my experience with >the 3200 pictures (including the three that seem to have started it, >Almadan, Fashion, and Brick). >I call color0 the color to be displayed when the bit pattern '0000' appears >in the bitmap data. I've found that color to be last in the pallettes. >I've found the 3200 palettes to be the reverse of the palettes in standard >$C1 type pictures. You're correct; the original point was whether or not an official standard 3200 color file format should reverse the palette data (something that all current 3200 color formats do). I have since ascertained from various people that there is NO worthwhile reason to detract from the elegance on the standard file format by specifying that it reverse the palette data; the original reversals were done quite arbitrarily by John Brooks, and there is no technical reason for preferring it to the 'simple' order of the kind used by $c1 and Apple Preferred ($c0/0002) formats. Todd Whitesel toddpw @ tybalt.caltech.edu