Re: [MiNT] XaAES palette colour handling

[Odd Skancke <ozk@atari.org>]

On Thu, 12 Feb 2004, Standa Opichal wrote:

> Hi!
>
> On Thu, 12 Feb 2004, Odd Skancke wrote:
>
> > > Why did you touch this piece of code? Because it doesn't work with your
> > > oVDI I suppose. Hmm, I also needed to change many things in the ARAnyM
> > > fVDI driver for that. Please read that code again and try to understand
> >
> >  Ok, I have reread that source, and now I'm more confused than ever. I
> > though that palettes set on one workstation should not affect any other
> > workstations (except that it does in CLUT modes).
>
> This is correct, of course.
>
> > Lets assume from now on that we're talking about non-clut modes. Under
> > such circumstances, changing the first 16 pens will not affect other
> > workstations (or other apps),
>
> It should not affect the other vwks at any time IMHO.

 Changing any color of one workstation should not affect colors of
antoher, not only the first 16... just to be clear :)

>
> > but still it renders concepts such as desktop themes useless. Do you want that?
>
> Here I completely don't understand you.
>
> When I open a new vwk and set the palette for that, after that I use this
> vwk to fix (convert) the CICON bitmaps to the screen color depth. Then I
> close that created one. XaAES doesn't handle (use) the palette when in
> CLUT mode. So this new virtual workstation is only used when in HC/TC
> modes (see where the vdih is passed to and trace down to see). And for
> this reason it doesn't hurt to set that all.

 Okie, I get you. This is very wrong. At least you must set the palette
back after changing it when in CLUT modes. And if you do that, you'll end
up with ugly blinking of colors while loading a resource file and this has
no valid RGB data.

>
> Concerning the TosWin2.rsc. Yes, this was yet another one that I needed to
> fix. Because it contained the extension (RSC color palette), but had it
> empty.
>
> The RGB = 0,0,0 is BLACK, right? So how do we know that it is really a
> flag saying that the palette is not correct? Perhaps if all of them are
> 0,0,0 then I would accept it, but otherwise it is wrong and the RSC
> palette extension needs to be stripeed off or filled with a correct values
> (like I did for the default widget.rsc - see the cvs log for that - I went
> to Interface and fixed the values to contain the needed ones).

 If all RGB values from pen 16 to 256 are all NULL's you can be pretty
sure Interface did not save a valid palette. Since this extension only
define a 256 color palette it looks like interface fills it up with NULL's
when no 256 color icons are present. My code do this check on all colors,
so if just one of the pens in the palette has a non-null value, it will be
used.

>
> > And now the thing I'm confused about;
> > I just cannot believe that changing, lets say, color 23 of one virtual
> > should change this colour of all other virtuals as well?
> >
> >  In CLUT modes, ovdi does not keep a separate palette, since such palettes
> > are global, i.e, a change in one palette affects the actual color
> > displayed, and in this case the opnvwk(), vs_color(), clsvwk() scheme will
> > work. However, I still think this is wrong.
>
> You confusion is not really needed. Get back to your original design.
> Color palette is always local to the vwk. This is correct. In CLUT mode
> the color palette loading is really just a waste of time, because it is
> not needed.

 I'm not sure what you mean by "my confusion is not really needed"? Get
back to my original design? Sorry, I dont understand.

 In CLUT mode, the best way would be to calculate color-distances between
the palette in the resource and the current system palette. Then convert
the cicons according to the resulting cross-reference table. I do this in
my object library, and it works great :) Perhaps VDI could support this
via vr_trnfm()? Convert a raster using a source and destination palette? I
will try that...

>
> >  As far as I know, there is no support from the VDI's side to set a
> > palette on an 'application basis', that is, setting palette that will
> > affect all workstations opened by a process.
>
> Correct.

 And I like that.

>
> >  What I can see from this, is that the virtual used to attribute the
> > resourcefile, is the virtual one must use to render the resource file to
> > screen, if using the palette in that resource file. I got around this
> > problem in my object library using color distance calculation when in 256
> > color LUT modes. I have plans to do something like that in XaAES as well,
> > which will make palette modifications not needed.
>
> Well it is still better to use that palette modification for HC/TC
> (non-CLUT) modes.

 Yes, agreed. The color distance caclulations I talked about above is only
needed in 256 (or higher) CLUT modes. With 16 colors (or less) the palette
is not supposed to change (first 16 pens, remember) But even in
HC/TC modes the first 16 pens should not be touched.

>
> > > that. I must have changed the driver color handling completely for this I
> > > must say....
> >
> >  I dont understand.. please explain.
>
> I had only a single palette and the fVDI driver interface was getting the
> pen number, but I didn't have access to the fVDI's palette there. So I
> changed the fVDI driver to accept directly the HW dependent color value
> (got from the palette lookup). This seems not to be that important in oVDI
> concern as you explained that you keep the palette local. And perhaps the
> driver doesn't need to know about it (it is already looked up, if
> applicable, before getting into the actual drawing routine).

 Oh. Well, yes, in oVDI the driver have access to all color information
needed. In oVDI, the drawing primitives are indipendant of the virtual
workstation structure itself. I use a scheme where a RASTER and a COLINF
structure provides the information drawing primitives need. Take a look :)


>
> best regards
>
> STan
>

-- 
 Regards,

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