Search options (Page 15 of 18)

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);
    }
}

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.

Right, so maybe I'm not the best person to try and fix this. My PC, apparently I've not set up audio at all under Linux, and my laptop, I'm getting the following when trying to load an .ogg:

AL lib: pulseaudio.c:612: Context did not connect: Access denied
GL_VERSION : 1.4 Mesa 7.11.2
ERROR Load Sound : non supported format

I will try and get my computer set up properly soon, but I don't think I can sort this bug any time soon

Very complete bug report, thanks. If it's happening in svn, it's not going to be my file I/O fixes, but if Anael wants, I can look at it tonight quickly?

Hmmm. I've just tried building Maratis with scons on Windows quickly, it seems to fail because it can't find zlib. Meh. I'll fix it and upload a new version. Also with the change to __init__.py which I swear I made...

I'll have a look whether the Windows version breaks with the .ogg. It's probably something to do with my file loading wrapper
EDIT: I can't fix Linux stuff until I get home tonight

With regards to DevIL. Not that I particularly advocate switching libraries at this stage, but FreeImage has a dual license so you can use it for commercial projects.

jurgel: Sorry, I was mistaken. With regards to having to make your game open source, I don't think that will be an issue, as you're just setting 3 C-strings inside the player. I guess I would have to check that to be 100% sure, but I guess if it's an issue you can get the player source code, change the strings it compiles with (something like [EMBEDDED MPROJECT GAME NAME GOES HERE]) replace it with the relevant ones for your project, and provide the source code of your change in case anyone wants it...
EDIT: I forgot to mention, the player executable, even though it has a different name after publishing, will still work the same as the standard player if you pass it another .mproj as a parameter. It remains entirely unchanged apart from the 3 strings.

Anael: No worries. I have a couple extra changes to make, such as allowing the developer to set the teakey for encrypting the package, maybe custom package extensions in case people want to obfuscate a little more... but I will wait for that until you've checked it into svn along with any OS X changes. Oh, and I'll add more comments and documentation. I'm good at forgetting to do that.

I'm sorry that I couldn't sort the OS X publishing myself, Macs are in surprisingly short supply at work and setting one up for a short while at lunch wouldn't make sense. I don't think it will be a big change. Mostly just moving the locations to the correct place inside the .app I guess. For now it doesn't embed the project either, but the code for that is in both the linux and windows sections, and it's fairly self explanitory

Hi, sorry, I don't know what happened with the linux compilation, I tested it and it seemed to work.

When I say I "push the project" I just overwrite some static strings in the executable. As far as I can see there's no more reason for the game to be gpl than because it is compiled with gcc.

Sorry I didn't include an example with this download, if you try any of the examples in the binary engine download from the maratis homepage and open it in the editor, if you select "publish project" from the file menu, it should work

Some final tests and the publishing should be uploaded tonight! As I said, some of the publishing steps will have to be updated for OS X because I don't really know where things should go. I guess probably all inside the .app somewhere...

But yes, I've basically just pushed the project data into the player application, which also has it's name changed to the name of the mproj. The data files are all added to the npk file apart from levels/ and meshs/ which, the folders are currently just copied in their entirety. The Game.dll is copied (if it exists) and I have also set up copying the plugin/ folder if it exists. Running the executable should then automagically run the game.

Just got to compile it all for Linux and check that it all works fine there, then I'm done and it will be uploaded

EDIT: Just a point, but the plugins will need to be kept up to date with the engine, otherwise they'll crash. Just ran a test with the water demo and was wondering why it wasn't working

EDIT: Linux test complete. I had to change a bit of code because I forgot to change the mode of the executable... but I added that I'm just going to reboot to Windows, update the VS2005 solution, clean out all build files etc, then upload Should be up in about 30 minutes

EDIT: Uploading

I managed to get scons building everything again. I even found out how to make it build separate libs, although I still need to do the refactor to make that much work.

When I build with scons, however, it doesn't copy all the necessary DLLs into the prod folder, as the Visual Studio solution does, which means that the publisher doesn't pick them up and realise that they need to be copied also. I ended up with a blue screen, when I copied the DLLs, it crashed. I'm not exactly sure what's going on. I'll have to see what I can find out tonight.

EDIT: just turns out I somehow copied the wrong DLLs

I had a look at embedding data before and, at compile time, it's simple. With GCC you can use objcopy to create an object with the correct symbols to link against. Of course this isn't really realistic as we want to do it when publishing.

There is the possibility of doing something like this:
http://www.daniweb.com/software-develop … ads/228424
I think the easiest way to do this is to make a constant somewhere within the executable, which can be 256 space characters, which can be searched for and replaced. Within the player, it can then first check to see if there's any data there (other than the spaces), then fall back to looking within the current directory for any files ending in .mproj

My USB HDD was playing silly buggers this morning, and I haven't checked what I've done recently into my git repository, so I might not be able to do the tests I was planning to today. I might have a fiddle with the project data and then merge it when I get home tonight.

I almost have the publishing done. I now have 10 separate publish steps, each of which can have multiple events, but not guaranteed as to the order. I have assumed the following steps
0 - clear the published/ directory. Shouldn't be used for anything else [complete]
1-4 - prepare game data. For game/plugins to implement
5 - package game data [complete]
6-8 prepare executable and copy, along with plugins etc [complete]
9 - run install scripts. For plugins to implement

I don't think that there should be any reason why this should be set in stone, but it seems like a reasonable guide for what happens when. I will try to work out writing directly to the package file, but that should be fairly simple. Will I be able to do something like Maratis::getInstance()->writeLevelBin() or something?

EDIT: For now I've just copied the contents of meshs/ and levels/ to the published/ directory and renamed the player executable to the projectname(.exe) I have yet to set up scons to split npk up, but I am confident that I can do that pretty quickly now I know how the build system is set up. I also want to test it quickly on Linux. As for OS X, I could, potentially, use one of the work Mac Mini's, if I have time tomorrow. Otherwise, I'll just upload it all again and let other people test it

Three things which I have come across. The first is something I've already mentioned, having the player renamed, the data packaged all makes for a more professional install, but with the .mproj file still in plaintext, and having to pass it as a parameter to the player executable makes it a little irksome. Maybe, as part of a publish step, we can embed the (binarised?) mproj? As the project is a fixed size (2 strings) we could potentially allocate space for it in the player executable and write the data in during the publishing?
Secondly, maybe allow to change icons for the executable, possibly just look if there are icons files in icons/ and again, write them into the player executable?
Finally, I don't think there's much reason why the "engine" can't be distributed with the player (and libraries) for all OSs/devices. Then from the editor (which would have to obviously be OS specific) when you click publish, it would ask you what you want to publish for (tick boxes?) and then run through all relevant publishing steps

None of those 3 are anything major, just something to think about I might even look into the embedded project, if I haven't got any art back to start work with on my project