Re: [MiNT] XaAES palette colour handling

[Standa Opichal <opichals@seznam.cz>]

Hi!

On Fri, 13 Feb 2004, Odd Skancke wrote:

> > ??? 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.
>
>  You obviouslely never used CLUT modes? In 256 color clut modes, changing
> a color immediately sets the corresponding hardware color index.

Do you mean vwk palette color change?

> This is why oVDI's workstations point to the same palette across vwk's,
> so that the palette data corresponds to the hardware color registers.
> Whenever vs_color() is called, it is the VDI's duty to make that
> change. Are you sure you understand what I mean here?

All vwk's are using the same palette (resp. HW registers)??? I supposed
the VDI work the same way as for TC/HC in CLUT (local palettes) and
therefore only the very first one opened (in fact the one used by AES)
were mapped to HW registers.

If all vwk's share the palette (HW registers) then you are right and I
don't really want to really set the palette for CLUT modes at all. Instead
I need to compute the color distance lookups.

>  And YES, YES, it is used in clut modes. How else did your code produce
> 254 hardware palette registers all NULL?

Yes, the code was actualy really on for CLUT, I agree.

So the solution to your problem is to disable it just for CLUT modes,
right? Or?

> > > 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?
>
>  If you refer to use vr_trnfm(), you wont fix anything using this method.
> vr_trnfm() will tranform the bitmaps to the same color indexes totally
> indipendant of current palette. Either you are confused about how to
> convert the bitmaps to device dependant format, and making sure they index
> the right color, or I am ;-) You need to do color-distance calcs and build
> a cross-reference table between a source and destination palettes and then
> convert to device dependant format using the cross ref table to get the
> effect I think you want. Anyway, I dont understand how palette changes can
> help you here. Please tell me what you want to do.

This is obviously true for CLUTs. I agree that I didn't test it in CLUT
mode because I didn't understand how the palette are really mapped there
(to the HW registers for all vwk's). OK, let's disable it for 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.
>
>  Becaues it kills the idea of letting the user decide how he wants his
> desktop and standard AES look. Anything using the first 16 colors are to
> be handled as AES property. And I never said that the lower 16 colors wont
> change in another vwk in CLUT modes. You only have one set of hardware
> color registers in CLUT modes.. imagine the effect.

I was speaking about non-CLUT modes only actualy, because I didn't know
that there are really all vwk's using HW registers in CLUT modes. I can
imagine the effect, of course. In CLUT mode it doesn't really make sense
to change the palette at all.

> > > 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.
>
>  Ok. Please read up on how CLUT modes work. In non-clut modes, there is no
> problem. Except from the fact that you still should not change the 16
> first pens. Do you want a situation where "this is legal with non-clut,
> but not with clut modes" ? That painter will most probably make sure he
> dont change any of the first 16 pens if he's going to use his art with
> AES.

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.

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

>  Tested code? Are you kidding me? You did not end up with a completely
> black screen, did you? 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.

I did end up with such a screen, of course for the first time. Believe me.
TosWin2: True.
Tested: quite heavily in TC mode.

>  And when you know the situation about CLUT modes and old-fashioned RSC
> editors, even knowing that Interface dont automatically save the palette
> in the RSC, do you want every XaAES user to edit all problem RSC's before
> they can use XaAES on Atari's with CLUT modes? Sorry, but this looks like
> a dirty hack to make your ArANYM driver happy.

As I said, let's diable the palette handling for CLUT modes for now until
the color distance computation is implemented.

> > I can also rebuild a new RPM of toswin2.6 for you (and also for the
> > other people of SpareMiNT) if you like...
>
>  No, thats not necessary. Thanks anyway.

Anyway, we should probable build it for the others for convenience.

> > 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?
>
>  Well, I know what the problem is. One set of hardware color registers
> (CLUT), bitmaps transformed to device dependant format has NOTHING to do
> with palette contents. Its not until the bitmap is drawn to screen the
> palette has a saying. Not even drawing the bitmap to offscreen buffer and
> copy the result over the original bitmap will do what you want to do.
> Reason? In CLUT modes, video-ram is a bunch of indexes to hardware color
> registers. You may change the value of these registers till you die, the
> bitmap still refer to the same register. With TC/HC the values in
> video-ram is the color value itself, so no problems. I need you to explain
> to me what exactly you want to achieve.

I got it. CLUT ... one palette across all vwk's, this is something that I
really missed. Sorry.

> > >  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. ;)
>
>  Does it build?

Yes, no problem. I'll try to go through the driver API and when I have
some time I'll write a driver for that. Could you please update the status
of needed binaries to run it? I don't know the emulator.prg and whether it
is needed to run in on VIDEL (for testing). Is there any further doc that
describes where to install which file? Configuration, etc... I know it is
in early stage, but I would still like to try that and especially add the
ARAnyM driver for that.

Thanks for your notes.

regards

STan