Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!jarthur!nntp-server.caltech.edu!tybalt.caltech.edu!toddpw
From: toddpw@tybalt.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple2
Subject: Re: 3200 file format standard (NO REVERSED PALETTES!)
Message-ID: <1990Aug1.231338.7751@laguna.ccsf.caltech.edu>
Date: 1 Aug 90 23:13:38 GMT
References: <430@fawlty.towers.oz>
Sender: news@laguna.ccsf.caltech.edu
Organization: California Institute of Technology
Lines: 25

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.edu