Re: [MiNT] XaAES palette colour handling

[Odd Skancke <ozk@atari.org>]

On Wed, 18 Feb 2004, Standa Opichal wrote:

> > > I didn't know that the CICON bitmaps are to be affected by a "desktop"
> > > palette. Is this something e.g. Atari Compendium says somewhere? Or where
> > > the "standard" came from?
> >
> >  Ok, this "standard" come from Atari themselves. I know I have read this
> > in the original Atari developer documentation, but I dont have that handy
> > right now. However, read what the Atari Compendium says under the "Using
> > Color" heading in section 7.8. (at least thats where I find it in my book)
> > If you have the .HYP file, look at "Using Color" in the VDI section.
>
> Hehe.. I'm one of the authors of the .HYP ;) so... looking into the .stg
> here:
>
> === Cut ===
> The first 16 VDI color registers are used by the operating system and
> should be avoided. If your application must change them, they should be
> restored when no longer needed.
> === End ===
>
> We are speaking about the OS, right?

 Yes, we are speaking of the OS, which I just call "the system" ;-)

>
> > > Hmm, so can we disable the CLUT modes until the nearest color computation
> > > is implemented and turn off the palette "constistency" check (the 0,0,0
> > > RGB check for the color 16 and above)?
> >
> >  We can disable it until we have color calcs for CLUT modes.
>
> Good.
>
> > The system pens (first 16) is never to be changed.
>
> Still not convinced ;)

 Well.. then I dont know what will convince you.

>
> > The palette "consistency" check should never go away.
>
> I see this as not necessary and failing when it is intentional for some
> strange reason :)
> It falls to just more code in the AES implementation that is not really
> needed and not really easy to read and understand already.

 I meant that this check needs to be there if the palette of resource
files are to be used at all. Only the first 16-pens are defined as
belonging to the system. That means using the palette for pens above the
first 16 is fine. The only differance between hardware CLUT modes (for
which we will use colordist calcs) and software CLUT modes is that you see
the effect of changing the palette immediately with hardware CLUT. You do
not see the effect until you draw with the new palette with software CLUT.

>
> > If a resource file has no palette, current system palette should be used
> > in any case, no matter if we're doing color calcs or not. An empty
> > palette could be thought of as "use default colors" for pens above 16.
> > This is not documented anywhere, but since we are about to implement
> > something new, we need to think things through. And thats my "suggestion".
>
> OK, something new.
>
> We are defining the OS behaviour, right? So why not to allow to change the
> lower 16 colors in the theme RSC (which would the XaAES adopt as system

 Yes, this is fine. This is what I've been trying to say all along. But
ONLY via themes. Since Themes is a "system configuration", in this case
look and feel, it should affect "the system" globally, ie. across
applications. Easy for application developers to let their app "follow"
the chosen look a user might want to do.

> colors) and then also allow to use these pens among applications in their
> private RSCs so that they would not affect the system look (by computing
> the color distance for CLUTs) in any way. See more below...

 The thing here is that every virtual workstation inhertis or gets a copy
(depending on wether its a hard/software clut) of the physical workstation
palette. And only the AES can change (or so it should be) this palette.
Now, if in CLUT mode (that is, hardware clut), having the AES change the
first 16 colors in the physical workstations palette will instantly set a
new color-theme. How well do you think this will work, if you allow
color-distance calculations on the lower 16 VDI pens, perhaps making the
bitmap contain referances to pens above the first 16?

 In TC/HC (which with our VDI is infact a software CLUT mode), things get
a bit more complicated regarding color-theme changes. The easiest way to
change color-theme now is to change the first 16 pens in the physical
workstation palette (like above). If, however, a different workstation is
used to draw CICONS on behalf of application, this vwk's palettes lower 16
colors also must change. When this is done, one needs to re-transform all
the cicon bitmaps, and perform a complete redraw of the screen. Again, if
you allow changing these first 16 pens on application basis, color themes
will not work.

>
> > > The theme may be done exactly by using a different RSC palette inside a
> > > theme RSC file. This way the AES may adopt the palette there as system one
> > > (set it to the HW registers) and my code would work as expected not caring
> > > about the first 16 pens. What is wrong with that?
> >
> >  How themes are implemented is beside the point.
>
> No it is not.

 Yes it is. The important thing is this "never change the first 16 pens
unless the AES is instucted to do so by the user". And the AES is "the
system" or the OS in this respect.

>
> > The point is that we do not change things that belong to the system, which
> > your code does on an application basis,
>
> Correct!
>
> > unless the user wants to. Like using themes to change system look.
>
> Exactly.
>
> > Your code would most likely be perfect in a "aes_settheme()" call or something.
>
> No. aes_settheme() would set the theme RSC palette to the system vwk as
> system colors IMO.

 Yes, and this is exactly what I mean.

>
> Once more:
>
> Theme RSC (OS feature):
>   Set the system palette and use the RSC as widgets (e.g.)

 Right.

> App RSC (using OS):
>   Compute CLUT transformation (or use the palette directly for CICONs in
>   non-CLUTs) and keep the display using the system palette unchanged.

 Correct. However, if you change here the mappings between what color
indexes the bitmaps originally used (remember, TC/HC is also a CLUT, only
it is software based), you will end up converting bitmaps originally being
"system icons" (that is, using only colors from the first 16 vdi pens) to
"non system" icons, which wont change or follow a theme change.

>
> > > IMHO the 16 pen rule makes more trouble than theme RSC palette taken as
> > > system one.
> >
> >  Why? Please explain.
>
> Because once we make the OS rules more easy to adopt by the application
> writers they would have hand free and may use any pen in the CICON bitmap.

 I can assure you that with the above, writing a "GEM or AES clean"
application will be extremely hard, if not impossible. As an application
developer, how do you make sure your application follows the themes
different users might install? The "if I stick to the first 16 pens, my
app's look will be 100% configurable through the AES" rule is the
absolutely easiest way for app developers to make sure their app follows
the look of the AES is currently runs on.

> I can't just imagine how it is complicated to say "do not use the lower 16
> colors for this picture" to some of the bitmap processing application just
> to be able to use it for some silly AES which is a part of some silly OS.
> Do you get it?

 No, I did not get this at all :-)

>
> 16 pen rule does the thing complicated and without this it is easier to do
> everything. The OS would handle the 16 pen protection on its own not
> providing the possibility to change that by user application.

 You are so wrong. Just plain and simple wrong ;-) Things (cicons, images,
whatever) drawn using the first 16 pens should not be remapped to use
other color indexes, because changes to these pens is what the AES do to
change themes. Do you understand?

 So, to be clear. Neither the palette of the first 16 pens, nor a bitmaps
reference to any of the first 16 pens should be changed. Thats why I said
color-distance calcs should not work with these pens (pens 0-15 in bitmap
always use pens 0-15 in a 1:1 translation).



-- 
 Regards,

 Odd Skancke - ozk.atari.org - http://assemsoft.atari.org