[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] XaAES: detect pixel-format-problem

-------------------------------------------------
From: "Lonny Pursell" <atari@bright.net>
Sent: Tuesday, December 01, 2009 5:52 AM
To: "[MiNT] Mailing-List" <mint@fishpool.com>
Subject: Re: [MiNT] XaAES: detect pixel-format-problem


If I use e.g.:

     {
     RECT r = {0,0,v->screen.w,v->screen.h};
     (*v->api->f_color)(v, 6 );
     (*v->api->gbar)( v, 0, &r );
     }

to set and draw a yellow color, the test succeeds and reports
the correct motorola-format.
This is only reliable if the palette is set accordingly. I think the first 
16
colors are always defined, and no one changes the palette at this stage
in the bootup-process, so it may be a working solution.
It is. In true-colour modes index 0-15 of the CLUT are always defined, and unless changed for the particular virtual workstation in use, they're always set to the 
standard Atari palette.
Interesting. So your saying ozks code it relying on some default values in the palette? That is not good. My method is to save the color , change it 
to white $FF, plot it, then restore that color back the way it was.
Your method is broken ;-) How do you know that $FF is white? You don't. The correct method is to use colour index 0, which is always white (or was that index 1?). Your method is exactly what causes LZH-Shell's background to be inverted on true-colour systems. It attempts to clear the background to white by writing $00, which happens 
to be black on most systems.
Jo Even 

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4650 (20091130) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com