Plugin system concept (Page 1 of 2)

+1.
I wanted to mention it in the engine feature request then thought there are lot of thing yet to implement, which are more important than this. Since anael is the only developer. This is a very good idea. Like Dark Basic Pro and Copercube. Than users will be able to use the plug ins without re compiling it.

Regards.

Ahh, so it's iOS which is the main issue again

Is it possible to use static factories for plugins?

#define MPLUGIN_CREATE(type) \
class MPluginConstructor##type \
{ \
MPluginConstructor##type() \
{ \
MEngine* engine = MEngine::getInstance(); \
engine->getPluginManager()->registerPlugin(new type) \
} \
}

I can see why plugins for a beta engine might be a problem, but then again, I think you might be surprised that people will maintain their own plugins and share them. Also, can build in a check when loading it, put a version number in Maratis through a #define and then compare to the one that the plugin is built with, before doing anything else, if it doesn't match, in the editor or somewhere, give a warning saying that it's potentially a problem.

Continuing from another thread. I have a few ideas for the plugins.

NOTE: this is a brain dump. Expect no coherency

Firstly, I guess it's unfair to not have plugin functionality for iOS so it would have to be extended to support static linking. My initial thought is to have a macro for initialising plugins, when compiled with something like M_PLUGIN_STATIC it would add a start(plugin)Plugin prototype otherwise it creates a startPlugin prototype. Likewise, there can be an implementation macro that wraps up both situations. I can't remember what happens with static constructors in staticly linked libraries, so I will have to take a look into that, but potentially that could provide the plugin initialisation.

Secondly, as Anael mentioned, separate plugins for engine/editor might be confusing for users, my suggestion is to, during publish, check whether the plugin is needed by MEngine, and not publish those that aren't. That way users can just unzip plugin packages into plugins/ and not worry about it.

Also, maybe get Maratis/MatatisPlayer to look in another directory for standard plugins as well as the project plugin directory. On Linux, maybe ~/.Maratis/plugins, %APPDATA%/.Maratis/plugins for Windows. This would give a nice central local repository. Maybe have a list of used plugins stored inside the .mproj (although when published, just load all the copied ones)

Finally, and most crazily, maybe having a repository for plugins which Maratis can check and download. There would be no need for the repository itself to be centralised, just a plugin list, probably in xml, with urls and checksums.

Anyway, that's a quick high level brain dump. It would require moving the plugin management into MEngine. Hmmm, I can think of a couple of reasons why my project might benefit from that. Maybe my next task?

Also, if we could scan the computer for gcc-arm (windows at least should have an environment variable if using devkitARM) then could potentially even link an iOS application from the editor... as everything should be interacting with Maratis, there would be little need for the iOS SDK... sorry off topic

Hi,

- for linux, do you have opengl drivers ? 3d is slow on my linux because there is no nvidia driver available, so it's using mesa (not really accelerated). If it react very slow also when the editor is empty, maybe there is an issue with X11 events ?

- the plugins was initially parsed in maratis folder /plugins/
but yes AppData would be better is a user doesn't own the write authorization of maratis dir.
And the project dir /plugins/ yes.

it works very simple normally, just need to parse the dir and load the plugin using MPlugin m_plugins.
need to be called just before maratis->loadGamePlugin()

3d drivers are sometime a problem on linux,
I'm still searching for my card, I probably need to install an older version of ubuntu (my card is a bit old)

For the commit, just leave me some days to look at the bin mesh thing, Mario (MarKill) also committed a new feature,
he made a custom shortcut system ! I'd like to validate this two things before a new contribution.

cool
thanks !

I still have mix feeling about it, for compatibility reasons, MGui is used only for tool things,
so we still need to find a good way to separate editor plugins and game plugins.

For example, a plugin code using MGui won't be compatible for embedded system (iOS, Android etc).
I'd like first that we take a decision on the editor/game separation plugins.

But after that, yes it should be dynamic.

Success. Well, partial for now anyway I have some of Maratis profiling I stuck profile tags in all the functions in MaratisUI and I'm about 1/2 way through Maratis when I realised that I actually want a different macro for Maratis, so only debug builds of the engine will even consider profiling but games can add profiling to whatever they want.

Anyway, no MGui output yet, just stdout for now, pastebin'd to give a quick idea
http://pastebin.ca/2108407

PS. I don't have a clue why it's giving <unprofiled> 1083546%

Sure, it already has a stream writer built into Shiny Profiler. I can easily add a file output, maybe before closing. The stdout stuff was just to check that things were being profiled correctly

I wasn't planning on doing a MGui output window until I was sure I had Maratis fully tagged and the profiler giving valid information.

Hi,

I understand, I also have a lot of work those days and was not able to finish the level bin thing, I'm hardly find time to respond to mails and clean the forum (lots of bots...).

The version thing can be a good idea to avoid crashing, how do you see it ? MEngine returning a version value ?

For drawing a child window, there is different ways, by making MGui dynamic yes, but I'm not sure the memory management is safe for shared library right now, as it was always static. If you create a new window from a plugin, it won't be deleted the right way when the plugin will be unloaded.

The other way from a plugin is to create a custom MGame class and change the draw() function to write text.

Finally, for drawing things directly it is also using MGame::draw class,
you can simply use MRenderingContext :

    // to draw in 2d

    MRenderingContext * render = MEngine::getInstance()->getRenderingContext();
    render->setViewport(0, 0, width, height);
    
    // set ortho projection
    render->setMatrixMode(M_MATRIX_PROJECTION);
    render->loadIdentity();
    
    render->setOrthoView(0.0f, (float)width, (float)height, 0.0f, 1.0f, -1.0f);
    
    render->setMatrixMode(M_MATRIX_MODELVIEW);
    render->loadIdentity();

    // draw a quad

    MVector2 vertices[8];

    render->disableNormalArray();
    render->disableTexCoordArray();
    render->disableColorArray();
    render->enableVertexArray();

    vertices[0] = MVector2(position.x, position.y);
    vertices[1] = MVector2(position.x, position.y + scale.y);
    vertices[3] = MVector2(position.x + scale.x, position.y + scale.y);
    vertices[2] = MVector2(position.x + scale.x, position.y);

    render->setVertexPointer(M_FLOAT, 2, vertices);
    render->drawArray(M_PRIMITIVE_TRIANGLE_STRIP, 0, 4);

You can use all the core drawing functions of MRenderingContext like that and mix it with the engine drawing.

The problem of including Love2d is that the drawing will not use MRenderingContext, it can work on the current Maratis as it uses OpenGL but will break the portability scheme.

For the version number, passing it inside StartPlugin will break the current plugins, it could be either using MEngine or a global variable (a define like M_ENGINE_VERSION ? ; could a macro update it depending on svn version ?).

For MGui, basically we should remove all the new and delete direct calls and replace it, like for MEngine by ::getNew() and ->destroy() class function. MaratisUI.cpp should be updated too to not use "new" but getNew when creating the gui.

So, I've finally got around to doing some of this Love plugin/MGui.dll stuff. The obvious first stage is to get MGui building as a DLL, which works fine using scons, but in the VS project, after a bit of rearranging and stuff, I've noticed that MGui.cpp includes MDevILLoader.h, which is in Maratis/Common/MLoaders... Not really a great place for MGui to access. Is there any reason why this is used directly, or why it's not using MEngine::m_imageLoader?

Unfortunately I can't devote an awful lot of time to this right now, as well as work, I sort of have 3-ish other projects :S My actual game, the tutorial series which I have a few more things to write up, and the Maratis3D/Love2D mash up (plus the mini profiler, which has the time profiling done, I'm just waiting for access to MGui properly so I can create a profiler window)