Re: [MiNT] XaAES palette colour handling

[Odd Skancke <ozk@atari.org>]

 Standa, could you please check your setup, I get your replies twice.


On Fri, 13 Feb 2004, Standa Opichal wrote:

> Hi!
>
> On Thu, 12 Feb 2004, Odd Skancke wrote:
>
> > > > Lets assume from now on that we're talking about non-clut modes. Under
>
> Crystal now. Of course any color change doesn't affect another vwk...
>
> > > 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.

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

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

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

 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.

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

 Obviousely, TC/HC modes do not suffer these problems.

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

 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.

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

>
> 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.
 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. Please dont call it tested code when its not!
 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.

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

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

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


-- 
 Regards,

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