[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] XaAES palette colour handling
On Wed, 11 Feb 2004, Standa Opichal wrote:
> Hi Odd!
>
> Regarding your commit: 2004-01-22 Thursday 18:37 ozk
>
> * xaaes/src/xa_rsrc.c (1.7):
>
> Fixed idiotic color handling in LoadResources. The first 16 VDI
> pens are not to be changed on an application basis! Also there is
> no guarantee that the RSC file contains a valid RGB palette for
> pens above the first 16.
>
> Few notes:
>
> * .RSC contains definitely _complete_ palette of colors!
> If not then we should check that by the maximum number of colors used
> in CICON blocks (which I actually did, but didn't commit because it
> come out as not needed since once they are not really used by the icons
> and so may be of any value) but definitely not by checking for 0
> values of RGB like you did.
Not true! When I detected this, loading TosWin2 resulted in ALL the
colors being set to black. TosWin's RSC only had a value for the first two
colors in its rsc. There is no mechanism to check how large the palette
is, except maybe check CICON's and assume it contains at least
most_colorful_cicon number of colors. And TosWin was not the only RSC
which did not have valid colors in its palette.
I found that when the RSC did not have a valid palette, all RGB data was
NULL's, so I think that it is a valid check. This problem extends far more
applications than TosWin2. I only detected it with TosWin2 first, as it is
loaded by the AES.
>
> * The first 16 pen colors are also present definitely. Perhaps you didn't
> update the widget.rsc (or possibly fix by e.g. Interface to contain
> valid palette - I fixed only the default one as I don't use any
> other). Remember that these pens are set to a newly created
> virtual workstation and so they are only applied to CICON color
> handling lower where they _may_ be used with any RGB values set
> legally.
Ofcourse the first 16 pens are present. But these first 16 pens are
user-definable on a global basis, NOT application basis. This is
documented by Atari.
Having different palette per application works fine IF you use HC/TC. Not
so great when you use a CLUT mode. Altho I agree that using a palette that
is present is a good idea.
>
> Why did you touch this piece of code? Because it doesn't work with your
> oVDI I suppose. Hmm, I also needed to change many things in the ARAnyM
> fVDI driver for that. Please read that code again and try to understand
> that. I must have changed the driver color handling completely for this I
> must say....
I touched this piece of code because it is illegal to mess with the first
16 pens. These are GLOBAL, i.e., they are user-definable, and should
reflect users choise across applications. They are AES's property. Because
it does not work with oVDI? Did you test your code on a CLUT based
graphics mode? As mentioned above, in TC/HC changing the palette of one
workstation does not affect the colours of another.
What must you change in fVDI driver? And my check for a 'NULL-palette' is
as good as any, I think. How else would you go about it? CICON checks?
>
> And finally: "idiotic" seems to me like too strong statement especially
> when you comited the changes I'm speaking about... Please avoid using such
> words in comments as they may be understood as offensive.
Well, going against valid documentation is not exactly brilliant either.
If you absolutely want to set the palette based on the one found in
resource files, you definately need to check if there is valid RGB data in
it. And you do not touch the first 16 pens. Not even when you're on a
non-CLUT graphics mode. I refuse to end up seeing nothing in 256 color
graphics modes because of no checks agains empty palettes in resource
files.
Offensive? Well, the code that rendered my display completely black was
offensive to both me and valid documentation, hence my comments. And oVDI
works, else I would not have detected this huge error ;-)
Clear enough?
--
Regards,
Odd Skancke - ozk.atari.org - http://assemsoft.atari.org