Re: [MiNT] fvdi: vs_color and stuff

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

>>> vs_color surely isn't at this place.
>>
>> Are you saying that it isn't possible to use vs_color() in a true
>> colour mode somewhere? Can you point to some display hardware where it
>
> This would be the consequence of the docs I've read (I wondered about this
> myself)
>
>> doesn't work?
>
> In the XaAES-code it actually draws some random color. Maybe I'll change my
> opinion about the usability of vs_color. What could be the reason for
> vs_color(1000,1000,0) not to result in the next pixel to be yellow? Is it
> possible to trace only calls to vs_color?
>
the actual values produced by "vs_color(1000,1000,0)" are gaurenteed
to be "full on red" and "full on green" and "full off blue" (resulting
in yellow). The important part here the "full on" part not the
resulting color, which is technically "arbitrary". What may be
apparent, especially if you consult that part of the "pixel detection
routine" posted elsewhere, is that if one know the color depth, the
one can decipher the resulting pixel read.

What Lonny's algorithm does, is multiple of these, not just one test,
and not just "one color", in his case he tests the RGB values
seperately, and adds adjustments for shift, where as XaAES only know
byte order, and similar (see the associated helper routine at the
beginning of the page with the pixel detection function in it..

basically: it is and "arbitrary value" resulting in a know value,
which is not the same as "a random value" (for either test or result).

this is a fundimental reason why a color index can NOT be used,
because you can never guarentee the index color vale, EVEN if you copy
is first and set it explicitly, for some reason, it may be adjust, and
you can not assume it will not be. a FULL RGB value, will always
equate to a FULL RGB value. It may be up to the test algorithm to
"devine" how that FULL RGB value is represented in binary form, again,
no the same as a "random value"

Paul