<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi John,<br><br>First, just for clarification,<br>"<br> ... that the support for palette changes[,] in just about every GEM driver <br>I'm aware of[,] is buggy.<br>"<br><br>Secondly, some questions.<br><br>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.)<br><br>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'.<br>There IS, now, one - well, for 216 (6-cubed) colors - derived from web-page 'universality'.<br><br>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.<br><br>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. :-)<br><br>Sincerely,<br><br>Thomas Clayton<br>who still
thinks in terms of a DRi PCGEMDOS - OR OS/O (O for Original) or OS/1.<br><br>'nough for now.<br><br><br><br><br><br>--- On <b>Fri, 2/24/12, John Elliott <i><jce@seasip.demon.co.uk></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: John Elliott <jce@seasip.demon.co.uk><br>Subject: [GEM Development] Today I Learned<br>To: gem-dev@simpits.org<br>Date: Friday, February 24, 2012, 3:02 PM<br><br><div class="plainMail"> ... that the support for palette changes in just about every GEM driver <br>I'm aware of is buggy.<br><br> What happens is: the RGB table is held in the driver data segment, so each<br>workstation (graphics context) has its own RGB table. This means that changes <br>made by vs_color() in one workstation won't be picked up by others. You can<br>see this happen by loading two copies of PALETTE.ACC, opening them both, <br>making a change in one, and
then clicking on the same colour in the other<br>one. <br><br> Since there is only one screen and only one palette, I'd expect a vs_color<br>in one workstation to be reflected if there's a vq_color in another. I'd be<br>interested to learn whether this is the case in Atari GEM; the documentation<br>here <<a href="http://toshyp.atari.org/en/007004.html#vs_color" target="_blank">http://toshyp.atari.org/en/007004.html#vs_color</a>> can be read as <br>implying it.<br><br>-- <br>John Elliott <br>_______________________________________________<br>gem-dev mailing list<br><a ymailto="mailto:gem-dev@simpits.org" href="/mc/compose?to=gem-dev@simpits.org">gem-dev@simpits.org</a><br><a href="http://www.simpits.org/mailman/listinfo/gem-dev" target="_blank">http://www.simpits.org/mailman/listinfo/gem-dev</a><br></div></blockquote></td></tr></table>