On Feb 8, 2006, at 12:06 PM, IOhannes m zmoelnig wrote:
james tittle wrote:
(the plugin structure was changed for the freeframe 1.0 spec)...I've
when? or rather: the Gem-support for FreeFrame happened after FreeFrame-1.0 spec. the newest files i get are from 2004.
...yeh, but I was using code for the dylib loading that came from pre-1.0 freeframe examples, in particular an example app called "FreeframeHostOSX"...but also, there's no mention of the change from dylibs to bundles in the developer documentation, and the freeframe sdk for osx only shows how to build plugins, not load them...curious documentation ommission! Even odder, it appears that we're the only open source implementation of freeframe on osx (gephex says they have it, but it's unreleased and likely not available on osx for the same reasons I faced)...
got the new bundle loading code working, but it's crashing when trying to actually processImage()...the most obvious problem in gdb is that the height and width don't seem to be passed to the plugin, and I'm having a hard time finding where this is filled out...this is working on linux, right?
as far as i can test (there are not that many plugins available on linux): pete's plugins work fine and gabor's ports of the xscreensavers do so as well (both are compiled by me)
the size of the frame is fixed for an instance of the plugin. therefore a check is done at the beginning of processImage(); on instatiation of a freeframe-plugin, a struct "vidinfo" of type VideoInfoStruct is passed, which holds the meta information of the frames.
...aha, a coupla well placed breakpoints later, and it seems that there's an osx problem with the format assignments at the start of processImage(): fr'instance, I loaded a movie with [colorspace RGBA<, but the m_image.format that gets passed to "format" is GL_YUV422_GEM! Obviously this isn't right, so i'll have to track down why...
btw, last time i tested, it also worked on w32....
...good to hear, I'll get it working here soon, I hope ;-)
thanx, jamie