[GEM] update && Re: [PD-dev] [GEM] update

[IOhannes zmoelnig]

hi all.

just commited one or two changes to the cvs.
1. Pixes/pix_texture now has automatic yuv2rgb conversion (on non-mac's 
-- i couldn't get my nvidia to texture yuv422-maps correctly)
2. Base/GemBase removed the "topmost"-warning for mac/linux (it somehow 
disturbed me;-))
more important: i have ifdef'ed the openGL-extensions-queries.
if gem was compiled without texture_rectangle-support (for instance, 
because the nvidia-GL-headers haven't been installed) but was run with 
drivers that supported it (for instance nvidia-drivers) textures became 
very black.
3. Copied yuv/[yuv_emboss] to Pixes/[pix_emboss] (to have one true 
yuv-effect for testing)
however, that was what i meant in one of my previous mails: yuv2pix is 
not yet finished since there are a lot of yuv-effects...
4. videoV4L: hope i have the colour-spaces right now
5. Base/GemPixUtil : added some more (integer!) colour-conversions and 
some other utilities like "setCsizeByFormat" (since the csize is bound 
to the format) and a string2format conversion ("grey" to GL_LUMINANCE).
these are of course very small changes. added some documentation of the 
code too.

i hope, i haven't broken any things.
after "cvs up; cvs ci" it compiles on my machine ;-)


chris clepper wrote:
>> which reminds me, we have to make ánd abstraction-folder.
> how do you want to include this in the GEM distribution?  the 
> abstractions have to be in the search path, so do we just write a script 
> to copy them into the extra folder or maybe alias them?
well, i have thought of putting them into Gem/abs/ (besides Gem/src/) ;-)
this brings us back to a very non-Gem specific problem of where to put 
abstractions in pd-runtime.
under linux there is a "make install" which installs the Gem.pd_linux 
and the documentation. So there is already a script which has to be 
extended.
Similar under win(tm).
How do you handle installation ?
Basically i would say: if the user has to copy the binary 
Gem.[pd_linux/pd_darwin/dll] by hand, s/he can copy the abstractions by 
hand to wherever s/he likes too. If there is an installer (there should 
be), this will take care of it.

personally i prefer separate directories for such things (that's why 
there is the doc/5.references/Gem directory) - although it maybe favours 
name-clashes. But while the prepend of "Gem/" to the help-symbol is no 
problem, a Gemabs path couldn't be made totally user-transparent.
<snip>
But: if pd would enable a global pdrc-file this could be easily patched
</snip>

> 
> ok, i will commit my changes, and hopefully it will work on linux.
i haven't had any problems yet

> 
> 
> maybe i'm just resisting the new system because jamie and i did a lot of 
> work to get the qt playback working well in the old system and now it 
> requires a rewrite for the new one.   i don't really understand why 
> pix_filmNEW has to handle all of the libs and APIs for every platform.   
> can there be a way to have a class that handles all of the libs needed 
> for a platform and then use pix_filmNEW as the public class?  i guess 
> this is more like the 'old way' with pix_filmLinux/Darwin/NT, but with 
> the individual libs exposed like in the new system.  is it possible to 
> really reuse the various libs on other platforms?  libmpeg doesn't work 
> on OSX just like the Mac quicktime doesn't work in linux.  maybe ffmpeg 
> is a possibility to use cross platform, but i haven't looked into it

hmm.
i thought pix_filmNEW doesn't handle all the APIs from the various libs.
this is done in film*.
So i guess your question is: Why are there calls for both filmDarwin and 
filmMPEG1 in the pix_filmNEW ?
if you wanted to open a special format, the first film*-class is tried.
if it fails to open the file (either because the format is not supported 
or the library isn't present on the OS) the next one is tried.
I thought it would be the same if a certain (existing) lib couldn't open 
a file or the lib wasn't present at all (either because of the OS or 
because nobody has installed it)
i don't think that this is a speed issue, since this is only one (or 
several)  void-call(s) when opening a file.
.
> 
> also, i forsee some problems with pix_videoNEW as well, but more on that 
> after i start on it...
> 
i am interested in this


mfg.as.dr
IOhannes