[SOLVED] How to import osc functionality into World ?

[kyriakos.marinis]

Hello Everyone! Is there anyone who can help me how to import osc functionality into a world? I am trying to make a plugin library based on the Dynamically Loading Library as Plugin example found in the Evaluation kit. I am loading oscdll.dll library with explicit linking in the oscplugin.cpp and trying to compile the oscplugin.cpp (scons) as plugin library but I am getting many errors like the following:

 

C:\Unigine Evaluation Kit\data\core\Unigine.h(136) : error C2065: 'engine' : undeclared identifier

C:\Unigine Evaluation Kit\data\core\Unigine.h(35) : error C2058: constant expression is not integral

C:\Unigine Evaluation Kit\data\core\Unigine.h(136) : fatal error C1903: unable to recover from previous error(s);

 

or

 

oscplugin.cpp(6) : fatal error C1083: Cannot open include file: 'UniginePlugin.h': No such file or directory

 

stopping compilation

scons: *** [oscplugin.dll] Error 2

scons: building terminated because of errors.

 

Furthermore, I am waiting to get the the compiled oscplugin.cpp as a plugin library .dll and load this library as extern_plugin. Is there someone who could help me, please? Or be able to see the big picture of this process and give suggestions?

 

Moreover, can I do this process with the Evaluation kit or I need the SDK?

 

Append, parts of code:

 

typedef void (*OSCOpen_)(void);

OSCOpen_ OSCOpenFunc;

 

HISTANCE hinstLib;

#define OUTPUT_BUFFER_SIZE 1024

 

int OSCLinkDLL(void) {

hinstLib = LoadLibrary("OSCDll.dll");

if (hinstLib) {

OSCOpenFunc = (OSCOpen_) GetProcAddress(hinstLib, "OSCOpen");

return 0;

}

else

return 1;

}

 

void OSCOpen(void) {

OSCOpenFunc();

}

 

class OscPlugin : public Plugin {

public:

OscPlugin() {}

virtual ~OscPlugin();

virtual int init();

virtual int shutdown();

virtual void update();

}

 

int OscPlugin::init() {

 

Log::warning("OSCOpenFunc init called\n");

Interpreter::addExternFunction("OSCOpenFunc",MakeExternFunction(&OSCOpenFunc));

return 1;

}

 

 

extern "C" UNIGINE_API void *CreatePlugin() {

return new OscPlugin();

}

extern "C" UNIGINE_API void *ReleasePlugin(void *plugin) {

delete static_cast<OscPlugin*>(plugin);

}

[ulf.schroeter]

Most probably you need the SDK. Evaluation version only allows scripting, but I think C++ API part is non-working.

[kyriakos.marinis]

Thank you for your reply! Do you believe that with the SDK, I will be able to compile the plugin library oscplugin.cpp as oscplugin.dll with explicit linking inside that loading oscdll.dll functions ? I am working many days on this process but unfortunately, I am following the step above without any luck.

 

Thanks in advance!

[ulf.schroeter]

I don't see any technical reason why this should not be possible. Key question is: what do you exactly want to do with OpenSoundControl (OSC?) in the UNIGINE context (meaning e.g. which kind of data and how exactly do you want to exchange via the plugin interface)

[kyriakos.marinis]

Using the external library oscdll.dll, I would like to export a number of functions and call them from the world script world.cpp. As such, theoretically, with explicit linking I am loading the oscdll.dll into the plugin and through the plugin Interface, I am trying to access these functions from my world. After that I would like to send OpenSoundControl messages to a world and control world parameters through external devices... for example: eyecon, touch interfaces, controllers and more ...

 

Here is the link with the OSC specification: http://opensoundcontrol.org/spec-1_0

and here is the oscdll that I am trying to link: http://www.frieder-w...OSC/OSC-DLL.htm

 

Does this make sense? Do you believe that there is wrong way here? Is it possible to avoid the explicit linking and follow another way to achieve this?

 

Thank you very much!

[ulf.schroeter]

I think plugin is perfectly right approach for interfacing with any dll code. The only challenge is data mapping and transfer between your plugin and UNIGINE script if there will be complex data structures, lots of API functions, callbacks etc involved (actually I don't know OSC, just had a short look on the specification and it seems to be a quite complex framework).

 

While possible from a technical point of view, this might involve lots of coding and type mapping. Therefore a simplistic UNINGINE script interface matching your needs should be designed upfront to get a feeling for complexity of your task.