[GEM-dev] Compiling Vertex Array stuff under OSX

IOhannes m zmoelnig zmoelnig at iem.at
Tue Oct 19 20:15:34 CEST 2004


B. Bogart wrote:
> Prehaps the pix_film object could print out a message when trying to 
> load a rgb codec in yuv space? 
well, this is a bit complicated.
there is no such thing as a "yuv space" into which an "rgb"-object (e.g. 
movie) is loaded.

the idea is that a pix-source supplies the image in a "native" way.
you should be able to override this "native" way with a "colourspace" 
(or "colorspace" if you prefer...) message.

all modifying objects should have methods for all colorspaces (if this 
is possible); if such the needed method has not been implemented (yet), 
an error-message is sent to the console.
> Any plans for automatic colourspace switching?
this has been discussed once; chris has argumented (and by now i agree) 
that automatic switching would be a sincere performance penalty: the 
problem is, that the system will choose to convert for you and you will 
not know why it get's sooo slow; if you have to do the conversion 
"manually" then you might optimize it easier

(but we could do automatic conversion + output to the console that 
conversion is done! this would tell the user what is going on (so slow) 
and it still would work)

pix-sinks (like [pix_texture]) should handle all colour-spaces.
since windos and linux don't know yuv-textures (at least i wasn't able 
to convince them to display correctly) they are automatically converted 
on these platforms.
on OSX, yuv-textures should theoretically be possible, however there are 
bugs in (older releases of) the drivers (for nvidia).
i don't know any failsave method to detect such bugs (except for looking 
at the green image, of course) and solve them on the application side 
(btw, i don't think that solving driver's bugs is a task for an application)

mfg.as.dr
IOhannes




More information about the GEM-dev mailing list