Re: [MiNT] XaAES sources for FreeMiNT 1.16.3

[Johan Klockars <johan@klockars.net>]

>> I don't understand why no one ever seems to use vq_scrninfo(). If it
>> has problems on some hardware, that should be easy to patch. Applying
>
> As you probably know, I posted possible fvdi-issues for months on this list,
> but none was cured as far as I know. So I'm just looking for ways to get it
> running as is.

Well, I'm not reading this list all the time, and certainly don't
often have time to look into "possible issues" with it. Still, the
code is available and you're free to tell me what is wrong with it, or
fix it yourself.
I am aware of one issue that has been pointed out to me, concerning
the clipping of italic text, but I don't seem to ever get around to
doing anything about it...

>> However, the real problem is that you keep getting 11101 rather than
>> 11111 for what should be maximum colour values.
>
> All the bits-analysis is nonsense: These are random-numbers (I needed

Uhm. They certainly are not random. You don't just _happen_ to get
11101 (instead of the 11111 you would expect) for every single maxed
out colour component in whatever combination.

> more than an hour to find this). Please read the thread about
> pixel-detection.

If you are talking about how vs_color() supposedly does not work for
non-CLUT colour modes, that is nonsense. How would you expect any
application whatsoever to be able to use any colour not in the
standard palette on a true colour screen?

What vs_color() will not do on a true colour screen is change the
colour of any pixel alread on the screen, since the palette it is
setting is just a virtual one (there must still be a palette/CLUT,
just a software based, or the VDI would be unusable). Still, anything
drawn using that palette index (on that specific virtual workstation)
afterwards will certainly use the new colour you just set.

See for example http://toshyp.atari.org/007004.htm#vs_color.

> Sure there are differences, in the initialization before the
> pixel_format-test.
> But I've found nothing that's obviously wrong. And as the used method is not
> allowed anyway, I don't search any longer. This is just academic.

So, how would you set which colours to use, if not via vs_color()?

I'm not claiming anything about the rest of whatever XaAES does, but
setting the colour via vs_color() is the only way to do it. If that
did not work, the only way you would be able to go outside the default
palette on a true colour display would be via vro_cpyfm()...

/Johan