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

[Paul Wratt <paul.wratt@gmail.com>]

On Tue, Dec 1, 2009 at 3:52 PM, Lonny Pursell <atari@bright.net> wrote:
> on 11/30/09 2:17 PM, Helmut Karlowski wrote:
>
>> What I found about the pixel-detection:
>>
>> detect_pixel_format uses vs_color to set a certain rgb-value. According
>> to Reschke's Atari-Bible this works only if
>> CLUT(color-lookup-table)-support is present. But it is not, neither in
>> 1.16.3 nor 1.17 (aranym, 16 bit). So it is understandable why the test
>> fails. I don't understand why it works in 1.16.3, but who wants to know
>> everything?
>>
>> 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.
>>
>> Maybe the GEM-Gurus can tell more about this.
>>
>> The bar may be smaller in a final version ..
>
> 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.
>

I think (guess?) that had the pixel detection function been any
"better", the issue would never have been seen. In this case it would
have covered an underlying change (problem?), that there is a
difference in the kernels is not in doubt, having had a bit more time
to think about it, is it possible that the change is NOT the kernel,
but MINTLIB, which has also changed, and is used by both XaAES & the
kernel.

MINTLIB handles the GEM side of things under MiNT does it not (if not
what does, as it has probably changed). Is this not the place that
contains the actual pieces of code that are the go between to
functions like "vcheckmode" and the ones that are used to fill XaAES's
"screen" object..

I think some of Ozk code may be from a time when underlying issue had
already arisen (in 1.17), but where not known, however, diff'ing XaAES
between 1.17 and 1.16.3 shows that XaAES has not changed in the area's
of rez setting and pixel format detection, just that a lot of work was
put into failed attempts to get unified (across the board) resolution
setting and/or changing to work

I would like to see patch in the style of Lonny's multi (multiple uni)
color pixel test as an upgrade to the current one, but from what he
says (extra shift info) some slight modification is required elsewhere
too (small as they might be), however I would not see this "patch"
applied until either this issue is resolved (fixed), or the reason for
it happening is found. It may be that it is actually more accurate
hardware info (or maybe just a bug?)

".. but who wants to know everything?" - unfortunately, I do :)

Paul