[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] fvdi: vs_color and stuff
Am 08.12.2009, 22:03 Uhr, schrieb Johan Klockars <johan@klockars.net>:
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...
I think it's overdue to do something in fvdi. As you may have noticed I am
not *the* expert on this.
If you are talking about the data you get back from vq_extnd() (the
...
This was new to me.
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. ;-)
I see: no color -> no table :-)
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?
Please, read the whole paragraph:
...
Why should I quote text that doesn't confirm my statement? :)
But I keep my previous statement: The values p_line draws are random.
Prove is that it works with palette-index 6, so it's not vro_cpyfm.
-Helmut