You are not logged in. Please login or register.
Hmmm, I can see why that's done then. I guess I can include the MDevILLoader then. Unless you would prefer registering a data loader inside MGui too. Thankfully MDataLoader is in MCore, so that shouldn't be too much of an issue. Generally speaking, MEngine can then setup the MGui image data loader to the same as what it uses.
Anyway, I'm no sure exactly when I'll get time to look at this. I might have time tonight, but it's quite possible I'll be busy again.
Aha! I got time! I've created the MGui project in Visual Studio, got it compiling, got Maratis linking to it. I added a MDataLoader to MGui for the images, which seems like the most sensible solution for now (but I can easily change it if you disagree) and it's all working fine. True, it crashes when it closes due to memory exceptions, but I assume that's due to the issue you mentioned. I will sort out the getNew() and destroy() functions next. I won't submit anything until it's been tested on VS2005, VS2010, scons on both Windows and Linux and even then only when you give the go-ahead 
With MGui as a dll, I can now start working on the plugins 
cool
thanks Philipp
I've finally got time to put all the getNew() and destroy() functions in for all of the MGui stuff... apart from MWindow, as this is a singleton instance. However, it is causing a crash on exit, so I think I will try and rewrite the singleton stuff so we can also destroy it when we need to. Not quite sure. Any idea why wglDeleteContext(m_hRC) in ~MWindow might be causing a crash somewhere in system dlls?
Anyway, I only replaced the new/delete in MaratisUI for now, there didn't seem any point in doing internal ones in MGui, as they would all be using the same memory, right? I'm not entirely sure where I go from here... but I think I'll start wrestling with Love2D 
Hi !
Can you send me a zip file ? I can try to take a look this week-end and tell you,
it's possible there is some stuff to clean in the memory, some people reported crash with linux and on windows with mingw.
Sure, I've been working on VC2010, so let me just update the VC2005 solution then I'll package it all up. I'll try and have a go at getting scons to build it too, but I can't guarantee that today unfortunately.
So, I've built with VC2005 and VC2010 and got the same issues. For now, I've only sorted the getNew() and destroy() in Maratis, not MaratisPlayer, so the player will almost certainly have more issues. I've also only sorted the release settings for the VC2010 solution for now as I was putting MGui etc into the Maratis binary directory tree. One strange thing that this showed up is that Maratis.exe, when run, requested MCoreDebug.dll, even though I built a release build and (as far as I know) only linked to release libraries... If I gave it MCoreDebug.dll, it would start loading, then crashed, if I renamed MCore.dll to MCoreDebug.dll, it asked for MCore.dll, so I copied MCore.dll and renamed the copy to MCoreDebug.dll and it worked perfectly. Well, apart from the crash on closing. None of this effects running from VC debugger, but still weird.
Ermmm, what else, I think that's about it. I think I've cut down the required libraries after the split, but I'm not 100% sure that it's not got extraneous links.
EDIT: Oh, I haven't got the plugin stuff working right now It was hardcoded for Linux in there at the moment with my home dir, so no plugins will work
Last edited by Nistur (2012-03-15 21:44:33)
Hmmm, what would be the nicest way to create plugins that need to add to the editor UI in some way? I can get MGui::getInstance to add to the necessary UI elements to to editor, but there doesn't seem to be a logical place to put it. Should I add a Windows menu next to File and Edit and have plugins add themselves to that menu, requiring each plugin to contain their functionality within a separate window?
sorry, I didn't have time to look at it, busy week-end...
from MGui instance you can create a new window that will be on top of the other, the only thing that need to be done very clean is to be sure the window is destroyed when the plugin is closed.
That's quite alright, I've had a busy weekend too. I was just wondering what I should do as, for example, the particle system I'm plugging in, the ideal thing would be to create a button next to the create entity/light/... buttons in order to create a new particle emitter. Of course the "simple" thing to do would be to just make anything like that a behaviour, but then the user would have to create an entity, make the mesh invisible and assign the behaviour, which is ok, was just wondering if we could allow for a slightly more simple way to extend the editor UI.
Anyway, I'll try and get this thing working for now with the entity+behaviour stuff, I can worry about those things later
Last edited by Nistur (2012-03-18 20:07:59)
I just had a quick fiddle with the plugin stuff... mainly because I was fiddling with the pspsdk stuff. The easiest way to do this is static linking everything together.
Anyway, I had a fiddle with the plugin system a little. I think I've got it more or less working. I should put this up with the disclaimer that I haven't actually tested this at all. It compiles and I _believe_ it should more or less work...
There's one thing that would need to be changed, which I didn't have time to finish doing on the train, and that's that MPlugin::Load currently takes the filename. This doesn't make sense in a static link context. For the static libraries, I would expect it to be something like plugin->Load("AwesomePlugin"); What I guess dynamic libraries could do is take that name and search relevant directories for AwesomePlugin.{dll,so,dylib} it doesn't do this right now. Anyway, just chucking this diff up for people to take a look at.
EDIT: It's just occured to me, with MPlugin being in Maratis/Common, you can't currently link against it using the MSDK setup. To get it to work, I guess it would have to be moved to MEngine?
Hi, that's interesting,
I'm a bit in a rush with the work but I will study it soon,
thank you man,
See you soon,
Anaël.
No worries. It was just something that I was fiddling with and thought I'd share it. As I said, I haven't actually tested this, but it's based on a similar system I wrote in a different project so it should be fairly ok.
Let me know what you think anyway. If you like it, I can tidy it up and submit it to svn.
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 3 official extensions. Copyright © 2003–2009 PunBB.