ISSLTC@NUSVM.BITNET (Lim Thye Chean) (06/06/91)
(Sorry, I have not subscribe to Info-Apple, so I cannot do a direct
reply. This is a reply to the answer on my original question)
Somebody mentioned in the net that he sees the 320 mode colour palette
as logical. I don't think so. Why don't Apple simply arrange the
the palette in such a way that the red in 320 mode corresponse to the
red in 640 mode, blue to blue, green to green, etc? Even 640 mode has
two grey colours that can corresponseto two grey colours in the 320
mode!
Yes, somebody may argue that not every 320 mode standard palette colour
has a 640 mode equivalence, but majority of them are the same. By
simply rearranging them to make the same one corresponse to each other
will surely greatly reduce the headache of programmers, even users...
just try Control Panel on the 320 mode, have you seen a blue RAM card
where green looks right on 640 mode? How about using a dark blue
background as the desktop colour in 640 mode which turns out into
BRIGHT RED in 320 mode? Have a nice 640 picture and switch to 320
mode and see almost all (except light blue, white, black) of the colours
change to something opposite... etc etc etc. It just does not make
any sense to me, why the 320 mode palette colour assignment is done
in this way.
***********************************************************************
*** Apple IIGS Forever ***
An Apple IIGS lover from Malaysia. A software engineer from Singapore.
-----------------------------------------------------------------------
Contact me at ISSLTC@NUSVM
Lim Thye Chean - Lim is my surname. My name is Thye Chean.
***********************************************************************toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (06/06/91)
ISSLTC@NUSVM.BITNET (Lim Thye Chean) writes: >Somebody mentioned in the net that he sees the 320 mode colour palette >as logical. I don't think so. Why don't Apple simply arrange the >the palette in such a way that the red in 320 mode corresponse to the >red in 640 mode, blue to blue, green to green, etc? Even 640 mode has >two grey colours that can corresponseto two grey colours in the 320 >mode! This is because the 320 mode palette was assigned so the color numbers would correspond to the color numbers used by the //e video generator (Lo-res and Double-Hires, and the text/background/border colors in the VGC). Todd Whitesel toddpw @ tybalt.caltech.edu
asong@pro-nbs.cts.com (Andi Song) (06/08/91)
In-Reply-To: message from toddpw@nntp-server.caltech.edu
:This is because the 320 mode palette was assigned so the color numbers
:would correspond to the color numbers used by the //e video generator
:(Lo-res and Double-Hires, and the text/background/border colors in the
:(VGC).
I don't get it. Why would the GS palette have to correspond to the
IIe palette? They are unrelated unless you want to convert the pics, but
Thye Chean is right; to have 320 and 640 compatibility makes much more
sense as they are more closely related than haveing 320 and IIe
compatilbilty(sp?), which is not as closely related or that often
converted.
----
ProLine: asong@pro-nbs
Internet: asong@pro-nbs.cts.com
UUCP: crash!pro-nbs!asong
ARPA: crash!pro-nbs!asong@nosc.miltoddpw@nntp-server.caltech.edu (Todd P. Whitesel) (06/09/91)
asong@pro-nbs.cts.com (Andi Song) writes: > I don't get it. Why would the GS palette have to correspond to the >IIe palette? They are unrelated unless you want to convert the pics, but >Thye Chean is right; to have 320 and 640 compatibility makes much more >sense as they are more closely related than haveing 320 and IIe >compatilbilty(sp?), which is not as closely related or that often >converted. Damn straight. It's just that these palettes were assigned back in the days of "backwards compatibility with a capital B". It should be possible to make an INIT that fixes the problem by replacing the default 320 mode palette with a 320 version of the dithered 640 palette, but I haven't gotten around to writing it yet. Todd Whitesel toddpw @ tybalt.caltech.edu
dlyons@Apple.COM (David A Lyons) (06/11/91)
In article <1991Jun9.030323.1164@nntp-server.caltech.edu> toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes: >[...] >Damn straight. It's just that these palettes were assigned back in the days >of "backwards compatibility with a capital B". It should be possible to make >an INIT that fixes the problem by replacing the default 320 mode palette with >a 320 version of the dithered 640 palette, but I haven't gotten around to >writing it yet. It seems a little strange to consider *changing* the color table behind an application's back as fixing a problem. But if that's what you want, the color values are already published in the May 1991 version of Apple IIgs Technical Note #63, Master Color Values (Table 3). In 0..F order, the color values are: $0000, $0008, $0880, $0888, (0..3) $0800, $0808, $0F80, $0F88, (4..7) $0080, $0088, $08F0, $08F8, (8..B) $0888, $088F, $0FF8, $0FFF (C..F) -- David A. Lyons, Apple Computer, Inc. | DAL Systems Apple II System Software Engineer | P.O. Box 875 America Online: Dave Lyons | Cupertino, CA 95015-0875 GEnie:DAVE.LYONS CompuServe:72177,3233 Internet:dlyons@apple.com My opinions are my own, not Apple's.
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (06/12/91)
dlyons@Apple.COM (David A Lyons) writes: >It seems a little strange to consider *changing* the color table behind an >application's back as fixing a problem. But if that's what you want, the First of all, the color table is not changed behind the application's back. A patch to InitColorTable would simply change what the default 320 mode color table is. Detecting the active status of the window manager would make it even more transparent since we only care about fixing things when there will be a desktop picture drawn. I and the person who started this thread would consider it a FIX because IMHO the 320 and 640 mode palettes should have been consistent to begin with. The deskpicture method you graciously supplied to us last year (which subsequently appeared in toolbox ref 3) does not account for the fact that the two standard color tables are inconsistent -- my current picture is colored properly for 640 mode but looks like a photographic negative when I run a 320 mode application. Since the default color tables are fixed in stone, there are two ways to get reasonable looking pictures in both graphics modes: patch out InitColorTable when the Window Manger is active remap the deskpicture image whenever the QD master SCB changes modes Since most 320 mode applications install custom color tables anyway, I don't see the InitColorTable method as a real problem. I see my deskpicture in screwball colors a lot more often than I see application colors that depend on the standard 320 mode color table. Todd Whitesel toddpw @ tybalt.caltech.edu