ShaderLoader plugin

[thatfunkymunki]

Hello, I'm currently working on forward porting the old ShaderLoader plugin to the most recent FFGL api version and am experiencing some issues. I finally was able to get it to compile with the latest resolume/ffgl library but I can't get anything to work- the UI elements appear when I add the plugin to resolume but none of the function calls occur when I interact with them. Am I missing something? I've put it all on github here https://github.com/thatfunkymunki/Shade ... Loader.cpp . Maybe I am missing something simple. When I attach the debugger, I see the ShaderLoader destructor is called as soon as it's done being loaded, even though everything returns FF_SUCCESS.

I plan to refactor this plugin to remove the weird dependency on SpoutPanel but in the meantime I'd like to just get it to work as-is.

[thatfunkymunki]

alright, it seems that the main reason the plugin was not loading was because FF_TYPE_EVENT has been removed from the FFGL lib that resolume provides? What is the proper way to get buttons into an FFGL plugin now?

[Joris]

FF_TYPE_EVENT is still there in both 32 and 64 bit. It's defined on line 144 of Freeframe.h. I use it myself on a few FFGL plugins.

I had a quick look at your cpp, but ShaderLoader is a huge plugin to just dive in to. Have you gotten in touch with Lynn?

[thatfunkymunki]

So it's definitely still defined in Freeframe.h but if you look in resolume/ffgl repo that is the only time that is referenced. None of the functions that handle parameters even touch FF_TYPE_EVENT. Are you sure that's not just dead code? I'll try submitting an issue to the original repo about 64bit support but there have been no commits on it in 3 years...

[Joris]

The definition is used by the host to decide what type of UI element to show.

You can use CFreeFrameGLPlugin::SetFloatParameter to handle pretty much every type aside from FF_PARAM_TEXT. For FF_TYPE_EVENT, the float argument will be 0.0 or 1.0 depending on the button's state.

As far as I know, there's never been specific handlers for params other than text. I suppose you could put in a pull request adding your own specifc SetEventParameter function, but that is for smarter people than myself.

[Joris]

Yeah, I just double checked the old repo on Sourceforge and it also does a basic cast to float for any param that is not FF_PARAM_TEXT.

Like I said, I use FF_PARAM_EVENT for two of my plugins. Both work as expected on 64 bit. I don't think FF_PARAM_EVENT is the cause of your problem.

[thatfunkymunki]

Alright, thanks. Based on your advice I have the plugin appearing to run 80% properly. It loads the shader from the path stored in the registry without issue. However, when LoadShaderFile() is called on a different shader, I get a segfault in nvogl64.dll. Any clues on how to troubleshoot this? The segfault occurs in FFGLShader.cpp at glCompileShader().

[leadedge]

Hi there. An excellent effort to attempt this.

My position at the moment is that I don't intend to update this project to FFGL 1.6, so if you succeed that will be a very good thing I am sure. I looked into FFGL 1.6 for 64bit but came across some peculiar problems and have not had time to continue with it. I am not using the Resolume FFGL source, however.

One thing to note is that ShaderToy has changed iGobalTime to iTime and added iDeltaTime, iFrame, iFrameRate and iSampleRate, so recent shaders using these will not work with the existing code.

I might update the ShaderMaker project for these uniforms because it is already 1.6. In fact you might get answers to many of your questions by looking at the ShaderMaker code.

I have recently updated ShaderToySender for the new uniforms. This is a stand-alone program equivalent to ShaderLoader, which produces a Spout output and is available to Spout supporters. There are some advantages over a Freeframe plugin such as loading the four textures and other things you can do in a stand-alone program but not in a plugin. If it does what you want, it might save some time. More than 200 shaders are included, checked, tweaked and working.

In fact the ShaderLoader plugin is stretching the boundaries of what Freeframe is designed for and it is really only by by good fortune that it does work.

If you want to remove the SpoutPanel user interface, you will not be able to replace it with any sort of dialog or it will freeze the Resolume GUI. That is the reason for the complicated process in the first place. You may be best to stick with a simple copy/paste of a shader file path. At least that will be remembered in a composition and you will not need a registry entry to save the shader path and recall it. Then changes happen when Resolume expects them to. Maybe you could try that to find out whether it solves your current problem.

I hope that you succeed in the project. I can only be of limited help because I am not using FFGL 1.6 and I have come across some strange problems as I said before.

My feeling is that a dedicated shader module for Resolume is the way to go, maybe ISF instead of ShaderToy.

Best,

Lynn

[l0de]

There are some advantages over a Freeframe plugin such as loading the four textures and other things you can do in a stand-alone program but not in a plugin. If it does what you want, it might save some time. More than 200 shaders are included, checked, tweaked and working.

Hey Lynn, you list that if you are a donator to spout you'll get a download link for shadertoysender in the thank you page, however this currently is not the case. Would you mind pming me the link? Thank you.

[leadedge]

There was a problem with the donation link on the home page which did not lead to the bonus downloads. I have sent you an email. I have repaired the home page donation button to lead to a donation page which provides a drop-down selection list that avoids the confusion.