Re: [MiNT] XaAES palette colour handling

[Standa Opichal <opichals@seznam.cz>]

Hi!

On Thu, 12 Feb 2004, Odd Skancke wrote:

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

Crystal now. Of course any color change doesn't affect another vwk...

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

??? It is a different vwk. So why should it blink? It doesn't affect any
vwk nor the system palette, right?
And finaly it is not used in CLUT modes so that doesn't matter that much,
I just might have saved a little time.

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

Again. The create vwk is _only_ used for fixing CICON bitmaps in XaAES and
so it really doesn't matter when the RGB are wrong there once they are not
used in the bitmap at all. Isn't it obvious?

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

Yes, this is the way for CLUT modes of course.

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

Sure. ;)

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

Why? When the ICON was drewn in 16 colors with different palette set then
all you need is to convert it according to the nearest color calculation,
of course. But why the lower 16 colors would be condemned to not to change
in another vwk? This is not logical to me.

> But even in HC/TC modes the first 16 pens should not be touched.

Why??? Any color can be changed. Imagine the painter would change the red
color (from the lower 16) to some of his favourites and draw the picture.
Why this should not work for him in non-CLUT? It is perfectly working -
actualy was in XaAES before you get into it.

What was your actual problem? The TosWin2.rsc? OK, let's put there a valid
palette (at least for the lower 16 colors, because it doesn't use more)
and see what other application doesn't work for you. I would do that
before you change a tested code. What do you say? I didn't have problems
with other than TosWin2 and the widget.rsc which were obviously edited by
some old fashioned RSC editor that filled a weird data in there for the
palette (lower 16 colors).

I can also rebuild a new RPM of toswin2.6 for you (and also for the
other people of SpareMiNT) if you like...

I would kindly ask you if you would spend more time on your changes and
put the functionality back and test the applications you have problems
with. I can send you a toswin2.rsc (and the widget.rsc is already correct
in CVS) - well I should fix and commit also the toswin2.rsc, but I only
worked in 1.16. branch... What do you say Odd? Will you try again, please?

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

I didn't have enough time yet to dig deep into oVDI code, but I'm
continuously testing building it. ;)

regards

STan