[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] XaAES palette colour handling



>  In CLUT mode, the best way would be to calculate color-distances between
> the palette in the resource and the current system palette. Then convert
> the cicons according to the resulting cross-reference table. I do this in
> my object library, and it works great :) Perhaps VDI could support this
> via vr_trnfm()? Convert a raster using a source and destination palette? I
> will try that...

NVDIv5 added various support for stuff like that, although I'm not
sure if this specific thing is in there in an easily used form.
I've not gotten around to adding support for any of those NVDIv5
functions in fVDI, but I intend to eventually (for the ones that make
sense).

> > I had only a single palette and the fVDI driver interface was getting the
> > pen number, but I didn't have access to the fVDI's palette there. So I

I remember that the ARAnyM driver palette handling used to be very wrong.

Did you add support for negative palette indices too now? They are used
(in fVDI, that is) to support the NVDIv5 functions that specify explicit
colours for fore- and backgrounds of various operations (bypassing the
standard VDI pen set functions). Not that I've ever seen any applications
use them, but they can be pretty neat. For example, they allow for drawing
yellow text on a blue background in a single operation.

>  Oh. Well, yes, in oVDI the driver have access to all color information

The fVDI engine does not keep track of the palette at all, except for
allocating space for it. The rest of the job is left to the drivers.

> needed. In oVDI, the drawing primitives are indipendant of the virtual
> workstation structure itself. I use a scheme where a RASTER and a COLINF

This is obviously a good idea, in general, since it makes the drivers
independent of the actual graphics API.

I still provide access to the colour palette, clip rectangle and
physical workstation (the latter mostly for drawing surface parameters)
via a pointer to the virtual workstation struct in fVDI (just about
everything else is passed as stack (the old assembly API is deprecated
and in the process of being removed) parameters).
I think the only driver function that still needs to access anything
more from the virtual workstation is accelerated text drawing.

The remaining dependencies on the virtual workstation structure will
likely be removed soon, and probably the ones on the physical one too.
It's definitely nicer if the drivers can be used without any need for
a VDI infra-structure.

-- 
  Chalmers University   | Why are these |  e-mail:   rand@cd.chalmers.se
     of Technology      |  .signatures  |
                        | so hard to do |  WWW:      http://www.klockars.net
   Gothenburg, Sweden   |     well?     |            (fVDI, MGIFv5, QLem)