[GEM Development] Today I Learned

[Thomas Clayton]

Hi John,

First, just for clarification,
"
  ... that the support for palette changes[,] in just about every GEM driver 
I'm aware of[,] is buggy.
"

Secondly, some questions.

For 16 color (or colour(?), in UK English) modes, I thought there was one, and only one, set of 16 for ALL computers - not JUST versions of GEM. Those 16 were THE same established ones for TI-99/4a, Apple II's., IBM CGA, EGA, and VGA, AND Macintoshes. (It was something like "native" choices. They MIGHT not LOOK the same (or be) BUT the video chip WOULD BE making THE same assignments for ANY system.)

It was when one 'went to' 256 colors that "variety" became an "issue". Is THIS what you're commenting upon? There wasn't A standard 'palette'.
There IS, now, one - well, for 216 (6-cubed) colors - derived from web-page 'universality'.

This, BTW, has been why I had been curious about SciTech Software's UniVESA (from back in the day) AND PC-GEM. (It would require 512KB, if not 1MB, V-RAM.) I had hoped to put you in contact (maybe I did, briefly) with (name escapes me) at SciTech (though he seemed to ONLY want to converse about the latest 32-bit 'incarnation': the universal SNAP driver (for Windows, for Linux and, my beloved, "OS/3"). They have (he has) since SOLD all that to some Canadian company and moved back to Australia (AFAIK). ( ___  Benton?  When I come across his name again, I'll post it.) SNAP (and UniVESA?) was, I thought, ?some what? open-source.

Anyway, the 'dream' was 216 standardized colors and 40 "I don't care" values to make up a deeper (256) color palette for PC-GEM that would allow an 'Arachne-like' app for GEM to be built. And, then, there are all those graphics app.s ... that could use them, also. :-)

Sincerely,

Thomas Clayton
who still thinks in terms of a DRi PCGEMDOS - OR OS/O (O for Original) or OS/1.

'nough for now.





--- On Fri, 2/24/12, John Elliott <jce at seasip.demon.co.uk> wrote:

From: John Elliott <jce at seasip.demon.co.uk>
Subject: [GEM Development] Today I Learned
To: gem-dev at simpits.org
Date: Friday, February 24, 2012, 3:02 PM

  ... that the support for palette changes in just about every GEM driver 
I'm aware of is buggy.

  What happens is: the RGB table is held in the driver data segment, so each
workstation (graphics context) has its own RGB table. This means that changes 
made by vs_color() in one workstation won't be picked up by others. You can
see this happen by loading two copies of PALETTE.ACC, opening them both, 
making a change in one, and then clicking on the same colour in the other
one. 

  Since there is only one screen and only one palette, I'd expect a vs_color
in one workstation to be reflected if there's a vq_color in another. I'd be
interested to learn whether this is the case in Atari GEM; the documentation
here <http://toshyp.atari.org/en/007004.html#vs_color> can be read as 
implying it.

-- 
John Elliott 
_______________________________________________
gem-dev mailing list
gem-dev at simpits.org
http://www.simpits.org/mailman/listinfo/gem-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.simpits.org/pipermail/gem-dev/attachments/20120225/49a63090/attachment.html