[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] XaAES sources for FreeMiNT 1.16.3
Am 08.12.2009, 13:47 Uhr, schrieb 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?
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)?
I suppose they use a natfeat-function or whatever.
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?
just a software based, or the VDI would be unusable). Still, anything
vs_color surely isn't at this place.
drawn using that palette index (on that specific virtual workstation)
I never said palette-index would not work.
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."
Maybe there has to be a palette and it isn't, I don't know.
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.
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()...
XaAES uses only default-palette-colors.
-Helmut