Re: [MiNT] XaAES palette colour handling

[Odd Skancke <ozk@atari.org>]

On Tue, 17 Feb 2004, Standa Opichal wrote:

> Hi Odd!
>
> On Fri, 13 Feb 2004, Odd Skancke wrote:
>
> > > So the solution to your problem is to disable it just for CLUT modes,
> > > right? Or?
> >
> >  Yes. If you use this method on non-clut modes, you need to make sure you
> > use the vwk you set palette for to draw ONLY the cicons in that resource.
> > Some things, like the AES look, 3-d drawing of objects, etc., should be
> > standardized. If you do heed the "dont touch first 16 pens" rule, you
> > dont need to take these precautions.
>
> Yes, If I take the rule yes.

 Please do.

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

>
> >  Right. Now I only gotta get you to agree with me on the first 16 pen
> > issue, and we're goaling ;-)
>
> Yes! ;)

 Good ;-)

>
> > > Well, when you do the color distance computation then it must work for the
> > > lower 16 colors as well as for the others in CLUT modes. Or not? So I
> > > can't see the incopatibility according to non-clut vs. clut mode.
> >
> >  No. Colors 0 - 15 are translated 1:1 between source and destination. That
> > is, color 0 in a cicon use color 0 in the destination palette. Again,
> > look, feel, users ability to use Themes, etc....
>
> This is something I still don't get. Why they would be mapped 1:1 when the
> painter have chosen to use them within the picture and I (as a user, or
> AES implementation, or whatever) decided to use different palette for my
> system. Here I see it as it is up to me to fix the color mapping e.g. via
> the nearest color method. If you have "Theme" then ok lets use it the same
> way - convert the palette to the requested. And in case the "Theme"
> implies a different palette usage then convert all the bitmaps in custom
> RSCs of applications to the requested (I would call it "desktop") palette
> which is by no means required to be the default defined by the original
> AES in TOS.

 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. Remapping differently will cause a mess.

 Icon designers should think about this when creating icons. If he wants
unique icons with the same look across different themes, he know this is
not possible on modes with color depths less than 8bpp. And in 8bpp (and
above) he must then use colors not "belonging to the system".

>
> > > >  TosWin was the first app I noticed this with. Lots of apps have a
> > > > non-valid palette in their RSC.
> > >
> > > Lots? Name few, please. If they are having wrong palette then you would
> > > disable the RSC palette handling in global?
> >
> >  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.

>
> > > > As for TosWin2, it only had valid RGB's for pens 0
> > > > and 1. That means with clut modes, not even the 1st 16 pens were
> > > > preserved.
> >
> >  in TC mode, you wont see the problems. Most of the time the first 16 pens
> > is consistent across palettes saved in the resource. Problem arises when a
> > user selects different look. Other pens, no problems :)
>
> In TC Whatever pen is OK IIRC. :)

 Nope, not really. Altho you dont see the effects until you try to change
something, like making a new theme, it is not 'OK' :)

>
> > > As I said, let's diable the palette handling for CLUT modes for now until
> > > the color distance computation is implemented.
> >
> >  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 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 :)

>
> >  At present, only 1, 4, 8 and 15/16 bpp are supported in oVDI engine. If
> > you can use any of those modes, you can have a look at tt.c (the ovdi
> > graphics driver for the TT), and be amazed at how little support oVDI
> > really needs to get going on new display hardware :) All you need to make
> > it run on Falcon is to add code to set VIDEL regs, fill in the RASTER
> > structure, and make sure you use the right pixel format (pf_falcon.h) I
> > will make Falcon driver as soon as I get the 2 bpp generic code in place.
>
> Good, you can find some details about the VIDEL registers in the ARAnyM
> code if you need them. It is really not obvious how to set them properly
> IIRC.

 I have the details I need, just needs to get the Falcon up running :)

>
> > Thats the only thing that remains before all original Atari modes are
> > supported. (Well, TT 8 bpp needs to be done too.)
>
> I'm quite short of time recently so that I didn't have a chance to get
> into the sources in detail.

 I know that feeling. Time is is my worse enemy.


-- 
 Regards,

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