Topic: Github mirror

I just thought I'd mention that, as all the current github mirrors of Maratis seem to be unmaintained, I have started my own one at

I will try to keep the mirror up to date with the official repository.

I've also made a minor change over the stock Maratis for it, it will now support multiple plugins. I haven't yet added static lib support into the plugins (which would be needed for iOS builds) because to do so, I would want to do some changes to the publish framework which I don't have time to do right now. Hopefully the plugin feature can be added back into the official stock Maratis soon too then we can all start making and sharing plugins.

Re: Github mirror

Suhweet smile

Let's plug the heck out of this!

Last edited by BitPuffin (2013-05-04 21:51:21)

Re: Github mirror


I've updated the github mirror to r203 from svn, and I've also made some more minor changes:

1. I extended MScriptContext::callFunction to be able to take functions within lua tables (so you can call, for example, player.update)
2. I added optional userdata to the registration of MBehavior factories. The reason for this is that you can then use one base class with different options (see #4)
3. I added MScriptContext::addScript which is pretty much the same as MScriptContext::runScript but only will load the script if the state has already been created, and won't clear the state, or do anything if it fails.
4. I made a plugin. It is pretty rough and dirty right now, but it works. If you drop this into the project folder and then create a "behaviors" folder along side it, and populate it with lua scripts, it will add one behaviour to Maratis for each script. It currently expects the script to have a similarly named table within it, with an update function. I haven't yet done the variable translation between lua and C++(/editor) but at least it's a start

Example behaviour script:

player = {
    update = function(object, behaviour)

Edit: I totally forgot, I also merged in a change from Sponk! Maratis editor is now themable! There are two themes provided (default and grey) although currently there's no way to switch them without recompiling

Let me know what you think

Last edited by Nistur (2013-06-08 16:28:48)

Re: Github mirror

Hey Nistur,

Very exciting stuff ! Thanks for sharing.

With an onBegin function and ability to set variables in the editor it will be a perfect tool.

Last edited by com3D (2013-06-09 07:28:30)

Re: Github mirror

Nistur: You actually can change the theme. Just change the 'default.theme' file in the 'gui' directory and you should be fine.

Re: Github mirror

com3D wrote:

Hey Nistur,

Very exciting stuff.

However, there seems to be a compatibility issue with regular Maratis.
Jules demo crashes the editor at loading, maybe due to the behaviors.


Edit: the bug is in the fork, not the plugin

I will take a look at this quickly Thanks for letting me know

Sponk wrote:

Nistur: You actually can change the theme. Just change the 'default.theme' file in the 'gui' directory and you should be fine.

Yes, I'm just thinking of serialising the current editor theme to a config file though. Then even without a GUI selector, people can (relatively) easily change the config without renaming files the whole time. (Plus this means that you could store the last loaded project directory for the file browser in the config file... which would make re-opening projects SO much easier)

Last edited by Nistur (2013-06-09 07:48:44)

Re: Github mirror


Sorry, in fact there was a conflict with another plugin.
I've updated my previous post.

Re: Github mirror

That's fine com3D. Which plugin was causing the problem?

com3D wrote:

With an onBegin function and ability to set variables in the editor it will be a perfect tool.

I did have a sample for the editor-lua variables but it was never finished and in my infinite wisdom, I deleted it. The main problem is that MVariable expects variables with the lifetime of the MBehavior, if I pull values from lua, the lua state manages their lifetime and will clean up the returned values shortly after they're returned (I believe) The only way I can think of getting around this is to load all the variables from lua on the first update and store them within the C++ class, and then every update pump the values to/from lua. The only problem is, if both the lua and the C++ side changes, which one takes precedence?

I know I can get around this by pushing a load of lua code to handle checking in... but I am not embedding any lua (yet) and I don't want to say "you can use this plugin, but you first need to add these huge lua scripts to get it to work" because that will remove from the simplicity.

The variables are definitely on the todo list, and pretty high, I just need to work out the best method of doing so.

As for onBegin. That's not a problem at all, while I'm at it, are there any other callbacks you'd be interested in?

Last edited by Nistur (2013-06-09 08:29:30)

Re: Github mirror

Nistur wrote:

What plugin was causing the problem?

In fact it was an incomplete plugin that I renamed 'Game.soZ' to deactivate it.
Your fork seems to load any file containing '.so', that's why wrong files can be loaded.

update = function(object, behaviour)

What is the purpose of the behavior parameter?

Are there any other callbacks you'd be interested in?

I think onBegin function for dealing with constants and initial setup is the top priority.
How can we deactivate/reactivate the behavior from other scripts ?

Re: Github mirror

Oh. Yes, I'm just checking for .so (/.dll/.dylib) I didn't think that I should make sure that there wasn't anything after it. I'll fix this.

The current Maratis lua API references objects by their pointer, and behaviours by their index within the object. At the moment all you can do with the behaviour ID is call {get,set}BehaviourVariable, which, as it's the current behaviour, is pretty pointless, even if the variables were to work. Basically, the reason I added it anyway was that it would then make it easier to build a more robust behaviour system in lua on top of it where you can reference behaviours on an object by name.

I'll have to think about the deactivation. I don't think there's currently a way without making an Active variable which update respects

Re: Github mirror

Just a small update that I've been playing about a bit the last few days on my commute, I present to you:


I will admit to have been "inspired" by Unity's PlayerPrefs system a little. At the moment it only reads/writes text files (XML) but I'm part way through adding some very basic binary file support. After that's done (maybe by the weekend) I will probably add some lua hooks in for save data.

For now, you can do as follows:

MSaveFile* save = MEngine::getInstance()->getNewSaveFile("path/to/save/file", M_SAVE_FILE_MODE_TEXT);

save->setString("some.key", "value");
save->setInt("some.other.key", 1);
save->setFloat("yet.another.key", 12.55f);

char testStr[256];
save->getString("some.key", testStr);
int testInt;
save->getInt("some.other.key", &testInt);
float testFloat;
save->getFloat("yet.another.key", &testFloat);


The class is pretty much an RIIA object, so it will load on construction and save on destruction, you can also call save/load manually if required. When the binary mode is added, it will be pretty much seamless. If you specify binary, but it loads text, when it saves again, it will convert it to binary and similarly the other way around. You can also specify M_SAVE_FILE_MODE_ANY and it will default to whatever it reads in, or binary if making a new file.

This can then be used internally for Maratis Editor to save preferences, such as the last opened project directory. I haven't done this yet... if anyone were to send me a pull request with this added, I would definitely appreciate it *hint hint* tongue

Anyway, let me know what you think.

Anaël, could we at some point discuss about potentially merging some of these changes back into the official repository? I would very much like it if we could continue to maintain this "community" Maratis branch and then I/you/someone could merge back changes that would be suitable for the official repo.

Re: Github mirror

Hi Nistur,
all that is interesting, I'm a bit busy those days so I wasn't very reactive.

For a merging I propose you commit the multiple plugins and the theme system if it was tested successfully.
I think MSaveFile would better be a separate plugin where you could add custom script function to be able to also call it from lua.

For the future : I started a rewrite of MGui to be able to make it a dynamic library, plus a transition to GLWF 3.0 for the system, for now I didn't started the modification of MaratisUI but at some point we should try to synchronise to not end up rewriting things two times.

Re: Github mirror

I'm well aware that a full time job can leave with you with no time (oh, very very aware) the reason behind the github fork, as I said was so that potentially "we", the community can try to work on the engine and then when the fixes are stable enough and got your approval, they can be merged up. I don't think anyone is complaining about anything here smile

I've already had a couple of "bugs" about the plugin system, such as com3D's one where I'm just checking for *.so*/*.dll*/*.dylib* which I think should probably be fixed before I submit it, but that's pretty minor.

With regards to making a plugin for MSaveFile, I can easily do that, but that means that we lose the ability to have editor savedata/preferences, unless I keep MSaveFile in MCore but move MSaveFileImpl to a plugin, but at the same time, that means that we have to have the plugin available both on an editor level (currently, I don't load editor plugins at all... so...)

I definitely agree with an overhaul of MGui because it's currently a bit difficult to extend the editor interface at all. But I think this is perfect for a separate thread.

Re: Github mirror

Sure, there is good ideas and it's interesting to have an experimental repository.

For MSaveFile, I don't think it should be an engine virtual system, a system like that don't need to be virtual,
it looks more an utility for saving variables, as a library if not as a plugin.

Re: Github mirror

I think there needs to be a further discussion then before MSaveFile is accepted into the official repository. If you don't see it as a core engine component, then it shouldn't be added. I think it would be a useful thing to have it available for Maratis as standard in some form, so I think we should try to find an agreeable solution. The options I think are:

1. Build it into Maratis/MSDK. The benefits here are that it's easy to integrate with lua, it's available both for game code and editor variables, and also, it's already done. The issues with it are that it is an enforced component in all projects, whether you need it or not.

2. Create it as a plugin. The only real benefit I see in this over #1 is that you can choose whether or not to have the support in your project. The disadvantage is that the editor can no longer access it as it isn't a general solution.*

3. Create it as a static lib. This is a pretty nice all-round solution. It can be linked into the editor executable and any plugins that need it, but the problem is that, for one, it creates extra complexity (having external static lib dependencies for plugins) and that it's no longer possible to easily expose save file functionality to lua without creating a plugin.

* Editor-specific plugins _should_ be a thing. I have intended to add them, but I haven't got around to it yet. But even that wouldn't solve this problem because you would then have two (identical?) plugins for a project that needs save data, which could cause confusion both for users, and for code compatiability (editor plugin is old version, project one is newer)

Anyway, as I said, I'm happy to go with whatever you want for this, but I think it needs a little further discussion regarding what is the best solution.

Re: Github mirror

In any case what can first be merged is the multiple plugins and the theme system where I totally agree in the design and the use of it.

For MSaveFile, I see the benefit of using it as a lua extension for a game, but I don't find it generic enough (nor virtual in essence) to be in the core, even saving editor preference would probably better use tinyxml directly in my opinion. I don't have any problem with the code or the structure, it's really a good work, but it's easy to add a feature and hard to remove one and I'm just here to preserve simplicity and general design.

Re: Github mirror

I've been wrestling with this a little. There is an issue with the plugin system currently. It works great for standalone plugins but if you want to reference them from the game plugin, you have to link against it... but you don't want to use dynamic linking because MPlugin is loading it manually anyway.

The issue is factory functions. I can't find a nice way to call, say MSaveFile::getNew within the game plugin, because it clearly needs to resolve it.

I have an idea, but I'm not sure whether I like it. There could be a base object type:

class MResource
    typedef MResource*(objectFactory)();
    static MResource* getNew(const char* type);
    static void addFactory(objectFactory factory);

then we can do something like this in the plugin header:

#define MSaveFileGetNew(save, file, mode) \
    save = (MSaveFile*)MResource::getNew("MSaveFile");\
    save->load(file, mode); \

and use it

MSaveFile* save = NULL;
MSaveFileGetNew(save, "someFile.sav", M_SAVE_FILE_BINARY);

Edit: renaming badly named example to what  implemented

Last edited by Nistur (2013-06-26 18:44:07)

Re: Github mirror

Update to github branch
1. Removed MSaveFile
2. Added more output on plugin load failure
3. Added MResource interface

Updates to MSaveFile
1. Added binary file support
2. Moved from Maratis to plugin
3. Implemented MResource interface
4. Lua integration
TODO for MSaveFile:
1. Unit tests
2. Extended lua integration
3. Hierarchical binary files

The lua integration is very straightforward, but I would also want to make a more "OOP-like" interface if possible. However without significantly extending MScript to allow exposing classes with something like luabind. The easier way to do it would be to do it in lua, but that would require either giving MScript a string of a lua "file" to load, or to extend the Maratis filesystem to allow named embedded files to be opened by M_fopen. So yes, still some work to do.

XML files are currently saved by breaking down a key such as "some.random.key" into hierarchical elements, but the binary files are saved with entirely flat paths, which I'd like to change, and that would mean I'd probably need to add file versioning also.

That's all for now smile

Edit: Updated to have a very basic lua interface

Last edited by Nistur (2013-06-26 20:56:06)

Re: Github mirror

MResource is interesting,
but once you registered a resource, how do you cast MResource* (in MSaveFileImpl* for example) ?
You still need a header for the plugin ?

Re: Github mirror

When using it in game (or from another plugin) it uses a macro to cast it. You still need the MSaveFile header to compile, but because it is pure virtual, it doesn't do any linking.

Re: Github mirror

ok, seems nice and it gives a practical approach for plugin extension,
good job.

Re: Github mirror

Thank you.

With regard to the embedded script stuff. What should you like to do? The easiest solution is to allow parsing of a lua string passed to MScript, but that technically could break the abstraction as it requires that MScript always deals with lua, and couldn't be extended to support other languages later. Personally I quite like the idea of allowing embedded files because it then lets us package small amounts of assets with plugins automatically

Re: Github mirror

What is your question ?
What do you mean embedding script ?

Re: Github mirror

Well, what I would like in future is to be able to write lua scripts like this:

savefile = MSaveFile("somesave.file")
savefile:setInt("some.key", 12)

or even to be able to serialise tables fully. To do this, it's possible to write the supporting code in C++, as you have with the vec3 code etc. but I feel that exposing this amount of stuff in the MScript interface would probably make it weaker. The alternative options are to either give MScript some lua string to parse (so, something like this would work script->Parse("-- some lua script\nprint(\"being printed from lua\")); ) or, alternatively, leave MScript as it is, and add to the Maratis "virtual filesystem" so that you can embed entire files, possibly as follows

extern const char* scriptData;
extern const int scriptSize;
MEmbedFile(scriptData, scriptSize, "MSaveFile/MSaveFile.lua");

which would allow for MScript to become more abstract if people want to extend it later and add more language support, then more files could be embedded to support the relevant language support. the embedded files could then be opened "normally" by M_fopen. Obviously this is more work than just making an MScript::Parse but... I think overall a better solution

Re: Github mirror

I'm not against a "script->parse(..)" function,
it's a choice to use it that can be made by the developers.

It should just come with a "script->getLangageName()"
just to make it safe and in case a plugin would need to support multiple langages.