Re: [MiNT] XaAES sources for FreeMiNT 1.16.3

[Johan Klockars <johan@klockars.net>]

>> 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
>
> But who do you think has the time?

I'm not saying that anyone has time, but we could hope so.
Still, I do actually have a bit more time these days than I've had for
the past couple of years, so...

>> 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?
>
> I thought you would tell me! How is it possible to display TC with 256
> colors (that's what fvdi claims to support)?

As I said, fVDI does what every other true colour VDI has always done:
uses a virtual palette.
It is the same thing with NVDI and for that matter the Falcon VDI (in
true colour mode).

> I suppose they use a natfeat-function or whatever.

fVDI is not an ARAnyM thing. It existed for years before there was an
ARAnyM and has dealt with 16 and 32 bit true colour since around '97.
There's nothing strange about it at all.

>> 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,
>
> Why does fvdi say there is no CLUT then?

If you are talking about the data you get back from vq_extnd() (the
CLUT flag), that flag is indeed set to 0 and the documentation I
linked to earlier claims that:
  0 = no CLUT
  1 = CLUT or pseudo-CLUT (true colour)

However, the two references I have to the VDI here on my bookshelves
(Compute!'s Technical Reference Guide, Atari ST, Volume One, VDI, and
Atari ST/STE Hårdfakta) say:
  0 = look up table available
  1 = look up table not available
and
  0 = look up table supported (as on color screens, where VDI drawing
pen index numbers are different from hardware colour register numbers)
  1 = Lookup table not supported (as on ST monochrome screen)

I also sometimes look at PC GEM documentation on the internet, and
just now I found this:
  1 if palette based, 0 if true colour

According to the mid two, returning 0 is correct for a true colour
mode. That is, the zero means that there _is_ some kind of
look-up-table, real or virtual. The fourth is a bit funny in saying 0
for true colour and 1 for palette, but I think they do not refer to
what we nowadays call "true colour".

Given the errors I've found in online Atari references before, I tend
to believe my books (and old PC GEM documentation). That said, I have
not actually checked what the Atari VDI returns for the three original
three modes, or the various ones on a Falcon (well, at least not these
past 10 years ;-), and I just found the following note in the
documentation for vq_extnd on the toshyp web page:

"Atari originaly misdocumented the workout[5] (CLUT) element,
reversing the values. The Falcon 030 and some third-party TrueColor
boards return the correct values, but some older boards may not."

So, there are different opinions on what the return value should
actually be, and thus little point in checking that flag at all.  ;-)
Anyway, AFAIK, the only non-CLUT mode (excluding true colour modes,
since those do have a pseudo-CLUT) that has ever existed on an Atari
machine is the original monochrome mode.

After seeing the PC GEM vq_extnd() documentation mentioned above, I
now lean towards the view that everything except ST monochrome should
indeed have a 1.  ;-)
Perhaps someone could verify what Atari actually did?

I apparently changed this value in the true colour drivers for fVDI
some time in its pre-CVS days (before 2001). The only thing that
remains is this somewhat cryptic comment:

	wk->screen.look_up_table = 0;			/* Was 1 (???)  Shouldn't be needed
(graphics_mode) */

>> just a software based, or the VDI would be unusable). Still, anything
>
> 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
doesn't work?

>> drawn using that palette index (on that specific virtual workstation)
>
> I never said palette-index would not work.

I am talking about setting the colour value for a palette index (any
index, 0-255) and then drawing using that.

>> See for example http://toshyp.atari.org/007004.htm#vs_color.
>
> "Note: The function can only be used if lookup table support is present."
> ...
> "If a device has more than 256 colours displayable simultaneously, it
> usually does not have a CLUT."

Please, read the whole paragraph:
If a device has more than 256 colours displayable simultaneously, it
usually does not have a CLUT. In that case the pixels do not contain a
colour value or index but a direct colour value in RGB (e.g. a pixel
with 32 bits has 8 unused bits, 8 bits for red, 8 bits for green and 8
bits for blue). This means that the VDI creates a pseudo-CLUT with 256
pens, and calling vs_color for one of these pens will not change the
colour of the pixels which have been drawn with this pen, though it
will change the colour of new pixels drawn with this pen.

It says explicitly that when there is no CLUT, the VDI creates a
pseudo-CLUT and things work the same way as usual (except, of course,
that palette changes do not affect previously drawn pixels).

> Maybe there has to be a palette and it isn't, I don't know.

There will always be a (pseudo-)palette in a true colour mode. You
couldn't use the VDI otherwise.

>> So, how would you set which colours to use, if not via vs_color()?
>
> Use a palette-index. vs_color is used only at one place in whole XaAES.

You don't set colours by using palette indices, you just use whatever
has been set before.

> XaAES uses only default-palette-colors.

In operation, an AES does not normally change colours because it would
be insane for it to do so on a system with an actual hardware CLUT. No
application would know what colours it was using any longer.
I suppose very few applications developed in the pre-true colour days
ever changed any palette entries either, since that obviously would
have affected the AES and any other applications that might have been
running.

/Johan