Re: [MiNT] XaAES palette colour handling

[Odd Skancke <ozk@atari.org>]

On Fri, 13 Feb 2004, Standa Opichal wrote:

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

 Yes.

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

 No. But the idea is actually good. In clut modes, only the owner of the
physical should be able to change the palette. And that is the AES. Now
we're close to the "AES owns the first 16 pens" idea, only now we're
talking the whole palette ;-) With a decent system palette, there would be
no need to change it if VDI had support for color calculations to begin
with. Now we're stuck with apps changing hte palette to show a picture,
for example.

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

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

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

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

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

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

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

 Ok, Rotide was one and two or three more before I changed the XaAES code.

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

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

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

 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?

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

 Yes.

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

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

 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.
Thats the only thing that remains before all original Atari modes are
supported. (Well, TT 8 bpp needs to be done too.)

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




-- 
 Regards,

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