Search options (Page 16 of 18)

If we're not changing the extension then things get quite simple to load. That's good

I haven't considered shaders, what will need to be done with them to load from the wrapper?

You _should_ be able to get around converting the xml files without temporary files. If we make it part of the publishing process, then the MBinariseMeshEvent can do something like:
- set package manager to writable (otherwise will write to OS files)
- loop through meshes
    - create/load file
    - write data
    - close file
- set package manager to non-writable
That way we don't have to deal with cleaning up after each step.

With regards to the final step of the publishing process, that shouldn't be too difficult to add as a late publish step

I've just looked up those 2 functions, changing them will be no problem, I'll do that now. I also see that readTextFile is how you load shaders. Nice. Another job done

Yes, I think that makes sense. Will you write the binarised file loading code then or should I try and add it myself?

I have managed to split up the package reading and writing code and it's now in Maratis/Common/MFileManager/MPackageManagerNPK.{cpp,h} whereas the interface (now called MPackageManagerContext) has remained in MEngine.

I am using a define which I can specify at compile time as to whether to add the writing code or not (M_PACKAGE_WRITABLE) and leaving empty functions for those which would require write access.

I'm just looking at how to publish the project. Do you want me to add an option into the File Menu, or maybe create a new menu, Project for example?

EDIT: I just had a thought, if all files to be added to the package had a .bin extension added, then it would make packaging files easy, just search for all files with .bin and add them For some file types, lua scripts for example, it would probably just mean renaming the file someScript.lua.bin

That's fine I enjoy doing this, so I'm not hurrying, I'm just excited

I'm glad the wrappers work fine Are you expecting to write directly into the package on publishing, or will you be writing the binary files out first, then package afterwards?

I have no idea why, but it happens quite often where the forum doesn't post my whole message. I usually catch it and edit but I was on the way out this morning too, so I didn't notice.

I was just saying that I'm starting with the publishing stuff now anyway, which involves adding the dev stuff to libnpk. While I'm doing that, I will move the package manager implementation to Maratis/MaratisPlayer and remove the dependancy for libnpk in MEngine. That will also allow for linking to different libraries for each executable.

I also want to try and work out what I can do about not keeping the packages in memory until the end of execution. I think simply loadPackage() loadLevel() unloadPackage() should work fine, especially for simple, trivial cases. However, if there are larger games made, it doesn't make sense at all to keep a whole package loaded the whole time. I think maybe, instead of calling unloadPackage, maybe have an offlinePackage which will read the file list, close the package, and just use the file list later, if more files are requested.

With regards to the code I wrote. I tried to make it as clear as possible, but it just meant to be a first pass, to get a feel for what people thought of the system. Now I know, I can continue

Thanks! Any welcome is better than none

The game design started off life about 3 years ago with my friend and I talking about point and click adventure games. So it's heritage will be there. However it's... evolved a bit since then.

It will be a 3rd person murder mystery set in a semi-fantasy pseudo Noir world with a dash of dark humour. I believe I was playing Discworld Noir at the time. However, rather than a point-click interaction, the player will control with a more normal, direct, control method. Much as I don't like the comparison, Heavy Rain is maybe a reasonable example.

The game design itself is probably far too big to undertake with a scattering of people during what little free time we have available, but the plan is to make a polished demo with one location, then try and use that to get interest in the project and build up the team.

As I think I said, the plan is to aim for desktop OSs. One reason behind that is that I can't do anything which comes into competition with my work. So no iOS, probably no Android. For now at least. Also, I don't have an iOS device and I can't afford to set up dev stuff for one. (I also don't want to give Apple any more money than they already have...) On the other hand, through work, I have contacts in Sony, and I've been told that, if I can get a demo made, they will make sure I can get a devkit, probably a Vita. So I think I might try and make Maratis work using the Homebrew PSP devkit to begin with, so I can send them a demo they can see on device.

I have a couple of pieces of concept art, but I don't really feel like sharing them yet I want to keep the suspense a little longer When I have the beginnings of the first location modelled, I think I might show the concept art, and maybe a glimpse of the location I have a very rough block out I made, but I'm the world's worst 3D artist, I'm waiting for my colleague to replace it with prettiness

Ahh, so it's iOS which is the main issue again

Is it possible to use static factories for plugins?

#define MPLUGIN_CREATE(type) \
class MPluginConstructor##type \
{ \
MPluginConstructor##type() \
{ \
MEngine* engine = MEngine::getInstance(); \
engine->getPluginManager()->registerPlugin(new type) \
} \
}

I can see why plugins for a beta engine might be a problem, but then again, I think you might be surprised that people will maintain their own plugins and share them. Also, can build in a check when loading it, put a version number in Maratis through a #define and then compare to the one that the plugin is built with, before doing anything else, if it doesn't match, in the editor or somewhere, give a warning saying that it's potentially a problem.

Uploading as I type this. [Done]
Maratis + libnpk 59.9MB

Also supplied with npk files for SponzaFPS and YoFrankie (script and image only)

EDIT: UPLOADED!

http://www.maratis3d.org/?p=500 <-- have you tried that example?

Good job.
I like the layout a lot. It's very clear and well thought out. If people contribute more examples the menu might get a bit unwieldy, so might be worth breaking it down. I assume this is entirely hand coded. Would it be simpler to have a wiki/blog engine and use that with a custom theme? Not wanting to knock your hard work. It is great, just might be easier to update, especially if you want to have more contributors

Also, I have to say I agree with zester, the background is a little distracting. It might be ok if it was toned down a bit and desaturated?

I am usually a Linux user too, which is one of the main reasons why I found and like Maratis so much. However, being a professional game developer, the one thing which I have come to love that Microsoft made is the debugger. I can, and have, used GDB. It just doesn't compare though. So for now I'm sticking with Windows for most of my coding (although only on my PC, when I'm away from home I use my laptop which only has Archlinux on it)

But yes, I like the look of premake4

I'll try and fix the SConscript and update the svn in a bit then

If you can get this working, I think it would be an ideal method myself as it would mean only maintaining one build system/project format and yet having support for everything. Scons does that to a degree and is quite good at it, but unfortunately doesn't create things like VS project files, so using an IDE requires maintaining the project separately.