Re: [MiNT] XaAES palette colour handling

[Standa Opichal <opichals@seznam.cz>]

Hi!

On Tue, 17 Feb 2004, Odd Skancke wrote:

> > >  Yes. As mentioned above, with non-clut modes, you either need to not
> > > touch the first 16 pens, or you need to make sure a vwk with the "systems
> > > 16 colors" are used to draw anything but the cicons. Or that is, you only
> > > use the vwk with the resource palette to draw the cicons. Do you follow
> > > me?
> >
> > I hope yes. But the rsc palette is only used for CICON bitmap
> > transformation and therefore I can use also the lower 16 colors. And still
> > 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?

>  If a painter (or icon designer) uses the first 16 pens, he also should be
> aware of the fact that users may change these 16 pens to suit their
> liking. Like, if a user wants blue-tones instead of gray-tones, all
> standard icons should change according to what the user wants. This wont
> happen if you dont restrict from changing the first 16 pens or maps the
> first 16 pens differently. The fist 16 pens should reflect the users
> settings, and everything initially using these should reflect users
> settings.

hmm.

> 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)?

>  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?

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

> > >  Thats good. Now, should we let the VDI take care of this? Anyone know if
> > > NVDI has vr_trnfm() support for this? If not, I would like to discuss a
> > > solution. Johan?
> >
> > Would be nice. I seem to remind some support of dithering directly in
> > NVDI, but didn't use that really.
>
>  I dont think dithering is what we need.

I know, but once they have dithering they may have also this ....

> > > > I got it. CLUT ... one palette across all vwk's, this is something that I
> > > > really missed. Sorry.
> > >
> > >  No probs. Just thought you knew about these issues after developing the
> > > fVDI driver :-)
> >
> > Well, as I wrote to the ARAnyM mailing list I didn't find enough
> > motivation to "bother" with CLUT modes in depth yet. It is still buggy
> > there.
>
>  Thats OK. But dont try to "fix" XaAES like that again, ok? And dont call
> something "tested code" when it turns out you didn't "bother" with CLUT
> modes. And before you ask someone to "read again and try to understand",
> make sure you know what you talk about. And, finally, fix things where the
> fixing needs to be done in the future, ok?
>
>  Thats the moral-talk for today :)

ok, ok... sorry. You also wan't that... say clean. :)

_best_ regards

STan