Search options (Page 49 of 60)

Hi,

for the texture, are you sure to use the good uv channel ?
You normally don't need to remap after the edge split, is it working when you don't apply it ?
Can you send a screen-shot of your object in Blender and in Maratis ?

The mproj file need to be a bin for sure,
after, where to put it can be optional.

A simple thing we can do first is to make MaratisPlayer search for a local mproj, to not have to use a command line if there is a project in the same folder.

Or yes, the mproj could be embedded, I personally don't know how to do that (except for mac, to put it inside an app).

Yes I was going to say that shaders uses readTextFile in MStringTool

- If you want to try doing the reading of the bin, I can send you the code of the writing when I finished it and you can tell me if you fell doing it. As I also need to do the writing of the level bin it can help.

- Good to know for the split of the lib

- For the publish button, it can go in the File menu (File > Publish Project).
Later if we need publishing options, we'll just open a new window with additional buttons/menus.

- For the generalized .bin, mh why not... let's think about it, I'm not sure it's so important to do it for all files.
> the bin files need to be also readable outside a package as a normal file.

Like keeping the original extension, it will be less risky than changing the extensions, as users can load data from a c++ plugin,
if they use something like "level->loadFont("fonts/arial.ttf");" it won't be possible to just change extensions as the filename will be in their code.

Just for the previous reason, changing the extension is in fact not an option.
Or we keep the same extension, or we add something after the filename for the modified files or for all the files.

My first idea was to write a temp file and then pack it, to not multiply the techniques, the other files are just imported.
I don't know, if it's simple to write directly to the pack why not, what do you think ?

Look, at some point I will need you to pause a bit so I can commit a version that compile everywhere, and maybe do some minor changes, for now I will wait, tell me when it can be done.

There is also a small thing to clean, there is two copies of zlib in 3rdparty, zlib was already used before and it's also in the npk source. We should try to have only one, but it's not urgent.

I will work on the mesh bin so.
Let me know how it goes

bye,

I started looking at it, it is very nice, good work !
I like the way it is done and it's a lot of commitment, thank you very much !

Before sending it to svn I have to try on every platform to check that everything compile,
there is also the mac project and the iOS publishing project to update.

I might move MPackage manager in another place, as a rule there is no 3rdparty dependencies in MCore and MEngine,
so it will probably be a module like the actual contexts, that's just a small detail to keep a door open in case someone want to use another packaging system, like they can change the physics engine.

I'm really happy to see things evolving like that, I hope we'll continue in the same way, good energy, good sharing

I have to go right now so I will start this afternoon,
see you later,

Anaël.

yes, doing real cross platform is a real challenge, specially when something like apple use very restrictive decisions, I'm trying to be really smooth with the moves of the engine. That's also why I paused the multi plugin system, I was sure it was ok with a one game plugin, but I was still not 100% sure of the pipeline for a multi plugin system.

More I think about it and more I don't find so important to take iOS into account.
The multi plugin system is more a "tool" and desktop thing.

It can be enabled for the next release.

ManualUse example is one of the simplest,
just initializing MCore + MEngine and loading some mesh.

What do you mean by subclassed ?

Cool,

yes a patch would be good to update svn !
Thanks !

Good, let us know how it is going

Officially for Maratis I want to support only one building system, because it has been already very hard to have one working simply and cross-platform, it was a big work for Davide Bacchet and we have a linux build in a big part thanks to that.

If at some point a better, simpler alternative is working as good as scons for all platform, we can think about switching to it, why not. Some details are more difficult than others, compiling the 3rdparty libs, making MCore/MEngine dynamic libs and linked properly for the plugin system dependency etc

What is the exact difference with scons ? Is it generating make-file and native compilers projects ?
What do you need to be installed in your computer ?