[of-dev] ofxShader addon

Pierre Proske pierre at digitalstar.net
Tue Jul 13 02:13:34 PDT 2010


Hi Kyle,

I got the shader manager updates to work on windows in both codeblocks and
vs2008.

Here's a new version...this one only monitors the data\ directory

> Awesommmmmee, thanks for the addon.
>
> It didn't initially compile on Windows in Code::Blocks for me:
>
> ofxShaderManagerUtils.h||In function `std::string getEventWin32()':|
> ofxShaderManagerUtils.h|170|error: `fnbuffer' was not declared in this
> scope|
> ofxShaderManagerUtils.h|172|error: `hDir' was not declared in this scope|
> ofxShaderManager.cpp||In member function `virtual void
> ofxShaderManager::threadedFunction()':|
> ofxShaderManager.cpp|233|error: `CreateFile' was not declared in this
> scope|
> ofxShaderManager.cpp|236|error: return-statement with a value, in
> function returning 'void'|
> ||=== Build finished: 4 errors, 0 warnings ===|
>
> I got rid of the hDir and fnbuffer by moving them to Utils and making
> them global. CreateFile was substituted for CreateFileA because it
> wasn't happy with Unicode pathnames.
>
> It runs now (I'm running against the ofxShader in my Google Code). But
> the directory updating doesn't seem to work. The best I can tell is that
> ReadDirectoryChangesW never returns.
>
> Should we move this to the forum and debug more there?
>
> Kyle
>
> Pierre Proske wrote:
>> Well it's Linux and Windows...just haven't tested the windows code.
>>
>> You could use a single toggle to re-load files....but automatically
>> reloading is much more fun....you should try it, it's like magic ;)
>>
>> If the manager keeps track of absolute path names, perhaps the same name
>> issue won't matter.
>>
>> Anyway, I'm willing to have a go at the OSX equivalent later on....it's
>> not so much work actually I don't think.
>>
>> On 11/07/10 20:26, Kyle McDonald wrote:
>>> Ah, so it's Linux-only right now... maybe we could make it
>>> cross-platform by just doing naive pull-based checks rather than
>>> relying on the OS to push changes via Inotify/kqueue/etc.?
>>>
>>> It would definitely be non-ideal for installation, but during
>>> development a single toggle that re-reads all the currently loaded
>>> files and compares the strings to the last time they were read...
>>> should only be a couple milliseconds, right? Plus, if you are using
>>> the actual paths rather than the full directories, you don't have the
>>> "same name" issue you mention.
>>>
>>> I think the slight slowdown from doing pull-based monitoring would be
>>> preferable over the complexity of getting ofxShaderManager cross
>>> platform.
>>>
>>> Kyle
>>
>> _______________________________________________
>> of-dev mailing list
>> of-dev at dev.openframeworks.cc
>> http://dev.openframeworks.cc/listinfo.cgi/of-dev-openframeworks.cc
> _______________________________________________
> of-dev mailing list
> of-dev at dev.openframeworks.cc
> http://dev.openframeworks.cc/listinfo.cgi/of-dev-openframeworks.cc
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ofxShaderManager.zip
Type: application/zip
Size: 8193 bytes
Desc: not available
URL: <http://dev.openframeworks.cc/pipermail/of-dev-openframeworks.cc/attachments/20100713/5faff995/attachment-0003.zip>


More information about the of-dev mailing list