Re: [MiNT] XaAES palette colour handling

[Standa Opichal <opichals@seznam.cz>]

Hi Odd!

On Fri, 13 Feb 2004, Odd Skancke wrote:

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

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

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

Yes! ;)

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

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

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

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

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

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

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

>  emulator.prg is only needed by the nova or et6k_nova drivers...

ok, thanks

best regards

STan