package file request (Page 5 of 7)

Anael: That's very impressive. I like Of course meshes should be loaded from xml during development, but when published, everyone wants faster loading It should be fully debugged and shouldn't need any maintenance then, surely.

When you submit the bin read/writing to svn along with the package stuff, I'll update the publishing to write the meshs to the npk

Ok, I can fix that quickly at lunch. There will be another version uploaded at 13:30 (GMT+0).

I've uploading the update now. I've just changed a little. I've removed the extra check in IsFileExist and modified M_fopen a little to account for this. I wanted to keep the design of MFile itself the same as it already is because it would be useful, for example for save files, as you can use it as an RIIA class and for that the class needs to exist, but can return errors on things like Read, Write, and can be checked with IsOpen. Hope this is acceptable.

Once the code is on svn, tested on all 3 OSs, I will start working on some platform independant updates, such as adding an API for the teakey. I would like to also expose publish steps to plugins, but that _would_ require some project file changes, so I'll not do that for now.

I am forced to do some small modifications to MFile and then to MPackageManagerNPK, there is a problem in the files new/delete, a file cannot be new in Maratis (by MPackageFileOpenHook) and be delete in MCore (by M_fclose) as MCore is a dynamic library the memory is not shared, at least on windows.

It's best if you don't make modifications the time everything is sent to svn (I think it's what you planned but just in case).

Something like that, it's ok I had the same problem with MDataRef at the time, it will be the same system, a "getNew" static function for the derivated class and a virtual "destroy" function, to avoid using new and delete directly.

Wow, that's great. It feels good to see my code online Once the publishing code is in, I will take a look at writing the binary meshes to the package Shouldn't take long

I've had an idea about how to allow publishing steps from plugins. If the MPublishEvent interface is moved to MEngine, along with MPublishContext, which will just have

virtual void addEvent(MPublishEvent* pubEvent) = 0;

then  MEngine can hold the publish context (will always be 0 in the player), plugins can then, in StartPlugin can do:

if(MEngine* engine = MEngine::getInstance())
{
    if(MPublishContext* pub = engine->getPublishContext())
    {
        pub->addEvent(new SomeCustomPublishEvent);
    }
}

No worries, I wasn't trying to rush you.

With regards to where to put it, I see the problem, I guess one way around it is, as you say, to split plugins into editor and engine plugins. The problem with that is that some might cover both, for example, the game plugin which might want specific publish steps. Although I guess this could be avoided by pulling out the publish functionality into smaller plugins...

Thanks, I guess I should have done some of that cleanup myself... I'm sorry.

I guess it would make it more difficult if you had 2 plugin directories? Something like ~/.Maratis/plugins for editor-only plugins and $PROJECT_DIR/plugins for game plugins which could potentially also have editor effects? Or game ones which have a dependancy, so StartPlugin returns bool, and it can query a list of editor/game dependencies, checking whether they're available and/or loaded (first? Would have to make sure there are no circular dependencies) But yes, I guess this conversation should be moved to the plugin thread. Not overly important now. It was just something that came to mind with the publishing.

I have no problem with the code being GPL. If I mistakingly made it zlib, it's because it originally was written in MEngine.

Hey, great! Thanks for sorting through my submission I will take a look at writing the mesh files directly to the package tomorrow Maybe expose the teakey and check that the game plugin can change it for publishing and loading. The only issue is that the plugin doesn't necessarily know that the package manager _will_ be the NPK one, so there would be no guarantee that the encryption needs 4 ints...

I noticed that, for the OS X publishing, you commented that all the data could be moved into the .app. I could probably do that pretty quickly too, although I would have no way to test it.

As requested, continued from PSP Thread

As I said, I find it quite difficult to follow a lot of the NPK code, but I believe once the package is opened, at least some of it is stored in RAM. I can't be totally sure yet, I would have to delve in a bit more. It's quite possible that it's doing some magic and only  loading the bits you request.

On a side point, when scanning through the headers to try and find the relevant structs, it turns out that there's a NPK read callback, can possibly tie that into an animated loading screen system... hmmmmmm

Unfortunately I was unable to do much testing during my lunch break as I had to sort out the billing on my website. I did, however, have a quick look through the npk code. Much as I'm still not 100% sure what it's doing, I've changed my mind and I think that the package isn't actually loaded. npk_read seems to open and read chunks of the package every time. So that would mean that leaving packages "mounted" should be acceptable. Will try and test further when I have time.