Search options (Page 47 of 60)

there is no problem with making a temp, we don't need to keep it after, it can be deleted after send to the package.

ok, basically MGui was designed to build maratis editor and is not designed for games, there is probably some code that can be used to create a more game suitable version, but right now it is probably very "system" and it force you to create the interface by code. Also, as you mention it is not dynamic, but it could be. The data system is just not using MEngine (only MCore).

I did some interface for games, and, as a designer I was more attracted to the freedom of 3d and of a visual editor. We can use Maratis to put "2d" meshs items using the ortho view (bottom view for ex to have x-y coords). The problem is the interaction that then need to be coded, by script or by c++. An interesting technique would be to create a bank of GUI behaviors (Menu, Button etc) that can reduce the code need and be setup visually.
> Like you sugest, to not have to go to blender to model a simple quad with a texture, we could add a meshLoader that takes a simple image file (jpg, gif or/and psd) and create a flat quad automatically. The rest can be done with a 3d tool if you want a real 3d button.

- child windows : yes you can create multiple screen using viewports and scissor test (with MRenderingContext).
> You can do that in a custom MGame class, the draw function.
> You can also draw multiple scenes at the same time but with different sub-window : your profiler text can be a MOText in a separate scene that you update.

As a general statement, what is missing today is some pre-coded behaviors, I only created very basic ones like Follow and Look-at. With a bigger bank of standard behaviors, it will reduce some code needs.

Hi, yes we need to convert all mesh in the mesh directory and sub-directory (i added an option to scan recursive in readDirectory, it returns global filenames if recursive)

You can create a temporary level if you don't want to touch the one in memory and load file by file :
Something like (doing by head, code is not 100% sure) :

MLevel * currentLevel = engine->getLevel();
MLevel * tempLevel = new MLevel();
engine->setLevel(tempLevel);

MMesh * mesh = MMesh::getNew();

(for all meshs)
{
    mesh->clear();
    if(engine->getMeshLoader()->loadData(filename, mesh))
        exportMeshBin(filenameDest, mesh);
    tempLevel->clear();

    (same for armatureAnim, texturesAnim and MaterialsAnim files)
}

mesh->destroy();
engine->setLevel(currentLevel);
SAFE_DELETE(tempLevel);

It will unfortunately load textures also for now,
but I will add an option to the xml mesh loader this week-end to not do it

you was right for the sleep, it put the cpu usage down.

I'm curious to see more of the comparison and test with big meshs and maybe unity. I also would like to be sure about what is happening with the used memory you recorded.

To check the svn version, I ran it with xcode and debug instruments, and opened/closed YoFrankie example,
Maratis was using 10mb at start > 32mb with YoFrankie, it came back at 10mb when closed.
The instruments recorded 4 leaks, basically 192bytes from Maratis and 400bytes from Bullet physics.

There is maybe some leak linked with the big mesh you use but I don't understand...

You said you used Sponza camera, is there a chance that the sponza mesh was still in memory ?
The website release of Maratis with Yo-frankie demo opened uses 36mo (I don't have a svn build where i am)

Some memory test would be very nice to do, there is not some build-in tools to debug it ? (I use one with xcode, but i don't know if it exist with visual or on linux)

thanks for the testing,
about the cpu usage, I noticed that it was high, I don't know how to reduce that it happen even with an empty program (we probably need to add a wait to the thread or something)

but for the memory usage, Im surprised, at start it should not take more than 25mb (not 71)
Maratis takes 22mb on my windows for ex

For the size of the psp ram, it also depend of the demo you want to do, if it's small it's ok, but it is good to anticipate the limitation if it's possible (it can be blocked by DevKitPro anyway).

(I should write it in the package topic) when a package is opened it takes ram ?

If I was you I'll first check the maximum data that can be put into the executable, it was a problem for me on devkitDS.
It's maybe different on devkitPSP...

I'm sure it will interest some users, after I don't know what is the performance of DevKit,
some years ago I used Nintendo DS homebrew before using the official kit, and it was really not the same, but it helped me building a prototype.

Just about the build, the iOS publishing example doesn't use scons at all, just xcode. I'm curious about premake, it sounds quite good, and updating all the projects when there is new versions of Maratis is currently very time consuming.

cool,
for the key, you can just pass a string, each manager will interpret it the way it need.

For osx yes, it is working like that, but it also possible to put the data/dylib into the Resources/ app sub-path, so it is more hidden.
I tested by copying it by hand.

[EDIT] it's working on my Linux : http://www.maratis3d.org/download/M_Lin … -rev93.zip