Re: [MiNT] XaAES palette colour handling

[Odd Skancke <ozk@atari.org>]

On Tue, 17 Feb 2004, Standa Opichal wrote:

> Hi!
>
> On Tue, 17 Feb 2004, Odd Skancke wrote:
>
> > > those colors may legally be used by the bitmap IMHO. The way it is used in
> > > XaAES it doesn't harm in any way so why to ban it?
> >
> >  Yes, exactly. The palette is used when transforming the CICON bitmap in
> > TC/HC modes. If the CICON is to be a "standard" CICON, it will contain
> > pens 0 - 16, and as such the 'systems' colors should be used here. If you
> > set own colors for all CICONS using pens 0 - 16, there is no way a user
> > can change the colors of "standard" icons. This is wrong. If this
> > continues, we'll end up with a situation where GEM's look is totally
> > unconfigurable, and looks is left to individual applicaions. Not good. A
> > good designer always uses pens above the first 16 to create a image or
> > special icons that is application-specific.
>
> 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.

> > Remapping differently will cause a mess.
>
> In the described usage scenario, yes.

>
> > > >  Ok, Rotide was one and two or three more before I changed the XaAES code.
> > >
> > > Does this apply also for the non-CLUT usage? Or was that at the time of
> > > your CLUT mode tests? I didn't meet much apps since the time I use the
> > > palette handling.
> >
> >  This was for CLUT, yes.
>
> 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. The system
pens (first 16) is never to be changed. The palette "consistency" check
should never go away. 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".

>
> >  Nope, not really. Altho you dont see the effects until you try to change
> > something, like making a new theme, it is not 'OK' :)
>
> 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. The point is that we do
not change things that belong to the system, which your code does on an
application basis, unless the user wants to.  Like using themes to change
system look. Your code would most likely be perfect in a "aes_settheme()"
call or something.

>
> IMHO the 16 pen rule makes more trouble than theme RSC palette taken as
> system one.

 Why? Please explain.


-- 
 Regards,

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