Getting started with Plugins

[SpiderPig]

I have the PluginSDK compiling and my own plugin loading in a program and a I'm able to get the description I've set.  I know how to export functions into the DLL but I want to be sure I'm doing this right.  How do I then get those functions into the program using the plugin?  Don't I need to include a header file that declares those functions and imports them from the DLL?

[Josh]

What functionality are you trying to add with the plugin? The engine will automatically retrieve the function pointers and use them internally. You don't need to access them yourself.

[SpiderPig]

I want to make a plugin that say, creates a voxel terrain, so I need to call a function called CreateVoxelTerrain().  Or are plugins only designed for the functions as shown here?

[Josh]

It would be possible to create a DLL or .static library that does this, but it would have to be linked with the exact same version of the engine library as the main program. Even then, I am not sure what would happen, since the engine has some hidden global variables. So that's not really a job for a plugin, you just need a regular old cpp files and header to add to your program.

[SpiderPig]

Oh okay.  I'll have a play around and see.  I was under the impression that plugins were a bit more usable than just for texture and model loading. etc.

[Josh]

Okay, let's try this...

[SpiderPig]

So I got it working to a degree... I can use commands from Ultra via the DLL but some things like you say rely on hidden globals.  I'm guessing one of those things is creating a model box?   Could these globals be passed to the DLL?  Anyway I've uploaded the project if you wanted to take a look.  You have to compile the DLL in rExport mode first then you comment / uncomment USE_PLUGIN to test the exported plugin or create it.  You probably have to change the path to include ultra too...

EaseFunctions.zip

[Josh]

It might be possible to copy function pointers across the executable and DLL, if I put a lot of extra work into it, but it would require the DLL to be recompiled every single time the engine headers had any changes at all, and shared pointers don't work between a DLL and executable. So why bother trying to do something C++ is not designed to do? What is the point of this?

[SpiderPig]

The point is to create plugins like many other engines have.  Plugins you don't want to reveal the source code too.

[Josh]

I don't think it is really possible in a practical way to create pre-compiled source code that uses the engine API and shares objects with an executable. If the code was just using your own classes, sure that would work, but C++ just isn't good at making modular code like that when the underlying API is subject to constant change.

Lua can be compiled to a binary file, so that might be a better option.

Maybe this will also work with C#, but I don't know enough about the final implementation of that binding code to say right now.

[Josh]

It would also be possible to compile a static library, and that would work with shared pointers and all the C++ data types, but if your library calls any engine commands then any little difference in the headers between what your code is compiled with and what the user's code is compiled with would result in random memory being written in the wrong place.

If anything, I would put your code in a static lib that doesn't include the engine, and then add a cpp file the user includes to make use of it.

[SpiderPig]

I didn't think about Lua, that could work.  I'll also look into the static library idea.  I've not built those before so don't really know the difference.