You are not logged in. Please login or register.
Maratis forum » Posts by Nistur
That's great, I'll sync and check it tonight on Linux 
Great to hear that you found the problem.
I had a look at what you did to add the mesh files and yes, I think that's much cleaner
I unfortunately can't do anything at lunch as some recruiter is going to call, and then I want to quickly try to export, import, load etc stuff, maybe give you some pretty things for the showcase courtesy of my friend Umar 
Using some more of his existing work to make sure I have an art pipeline I understand
No worries, I mean, for editor plugins, you can extend MPlugin a little to look for startEditorPlugin or something in order to make sure they don't overlap.
As for plugin code being compatible across embedded systems, I really wouldn't know, maybe it's possible to create a basic MGui iOS wrapper?
Anyway, as I said, I will work on it as it is now, when you give me the go-ahead, I will integrate it with whatever system you have in place then
You had me a little worried there for a second, m_buffer is a member of the MPackageFile and _should_ be cleaned up by it at the end of MWritablePackageFile::close (return MPackageFile::close(); )
And yeah, I think I made it about 10MB, which is far too big, but I'm not entirely sure what the best idea for a dynamic size buffer would be when we are expecting to keep writing to it.
No worries, also, do you have any issue with the plugins depending on MGui being a shared library? If I'm going to make a profiler window come up, it sort of makes sense, but if you have problems with it, I will work around it
Sure, I'll keep working and clean it up It will be here when you want it Along with maybe some little plugins
Hmmm, that's a good point, I potentially don't have 3D set up properly. I thought I had radeon-hd drivers. Worth finding out Maratis Editor itself isn't slow though, until I load a project.
As I said, I had some quick tests in just to get it working on my machine quickly, which worked pretty well, so I can clean that up and add the MProfilerContext interface (which is being implemented in the plugin I'm writing, if there's no profiler attached, it won't do anything). Any issues with me submitting this code? Do we want debug player/editor builds to profile Maratis itself and the release build to only profile the game(/plugins)?
The time profiler is practically done as it will just use shiny, I'll leave memory profiling for now until I have some nice output method. It currently will spew to stdout but should be able to rewrite the OGRE one to draw to a Maratis (child) window pretty easily.
You need openal to compile Maratis and, as Maratis is 32bit, trying to link to x64 won't work. Also, there is a copy of libsndfile provided with Maratis itself, using one in /usr/lib(32) will possibly create problems.
Why do you think the lib32 won't solve the problem?
For some reason, Maratis is running _really_ slowly under Linux for me. It takes about 2 minutes for any interaction to register. Much as it _does_ work, it's really unusable (at 4x2.4GHz that really shouldn't happen...)
I think this is a perfect time for me to try to add the profiler to see what's going on. The first thing that might be useful is to know where you put the sleep to reduce CPU usage. Or maybe we want to put a pause in to lock it at a maximum of, say 30fps?
Secondly, you said that the plugin system was currently hidden. I've found m_plugins hidden in MaratisPlayer (I assume there's a matching one in MaratisEditor) How did you go about populating this? Is this something that I can re-add simply?
EDIT: I've just put a quick check in Maratis::Maratis for now to try to load all the files in ~/.Maratis/plugins. (will be %APPDATA%/Maratis/plugins for Windows I guess when I tidy it up) I guess for game functionality plugins it can also search (projdir)/plugins in Maratis::start and MaratisPlayer::start. Does that sound acceptable?
I prefer development on open source OSs too in general, it's just that, when it comes to debugging, the visual studio debugger has so many nice features. It's possible to do most of them with gdb, but much as I usually live on the command line in Linux, the visual studio debugger is so polished that it makes life so much simpler. Like I said, the debugger is the one thing that I really love that Microsoft have made. Also, you can edit and continue. On a large project, that saves _hours_
I had a look at fossil before, it looks really cool. I am really falling in love with distributed version control (see my rant about a particular source control system beginning with P) however, I also like having somewhere to back up my work, preferably off site. Not having a big project means that I can't realistically expect other people to provide a backup mirror. As such, I'm going to be sticking with git for now Also, sourcerepo have provided me with redmine, which pretty much covers everything else I will definitely have more of a play around with fossil, it's good to know that it's worth looking into
No problem, I just got my linux install finally set up properly, so I can do development here The problem is that I built Maratis from svn and it crashed when trying to load the WaterGameDemo, on libsndfile. So I finally had a dig around as to how to build a debug version using scons.
Turns out, for whatever reason, I didn't put a null pointer check on the sound loader... oooops! Fix incoming shortly!
Also, is there any reason why libsndfile might not be able to read a .wav? :S
I will submit it in a few minutes, I've been tidying up. I don't really understand the binary stuff myself yet, so if you can have a quick look then it will probably be solved much quicker. It's also quite possible that I've done something stupid which I haven't seen. I will take another look at it tomorrow.
Errm, the has functions that I linked to are similar to md5sums, although for a smaller scale. They are usually a trade off between speed and potential clashes. The main use for them is comparing and storing strings, which are large and slow to work with. Most hash functions can hash arbitrary length strings into 32 bits with few clashes. Makes them useful for creating keys for std::maps 
EDIT: the code is submitted. I hope I haven't broken anything
I don't know whether to submit it tonight. The mesh file loading was a simple fix, it was a combination of not stripping the project filename to a local filename when embedding it, and embedding it with .exe (it should be .mproj for the embedding to work properly)
The problem is now, I still can't reliably export bin files, and I also can't reliably load them. I guess I will tidy up what I can, then comment out the section which doesn't work, or wrap it in #ifdef, so you can have a look to see if I'm doing anything silly.
I'll try and sort the materials and then submit tonight, maybe after checking what's happening with the loading and why it's taking the same time for both xml and binary versions. Probably after a round of filling in comments everywhere
Also, what do you think about the method for calculating a teakey by hashing a passphrase? If it's acceptable, where would you like the hash function kept, and do you have a preference as to which hash function? There are a load here with downloads here. Originally I just chose one of those to test it.
Is there anything else you would like to be added this weekend that comes to mind? I'm going quickly add functionality to change the package extension, if it's desired. Then I think I'm done with it
EDIT: It seems that for some reason, the published executable is still referencing the original project location, so yes, it was still picking up the original files. I have no idea how this happened, but shouldn't be too hard to fix.
No problem. Might help my mumbling a bit if I wrote it first
I still haven't had time to do any of this 
the combination of work, personal life, and trying to get my first proper contribution to Maratis polished nicely has put this "on the back burner" for a bit. I will try and get something done this weekend though
Ok, so I've tested it with Visual Studio builds and Windows scons builds and it works fine on almost all the examples, just the Demos project seems to be playing up a little bit. I'm not sure what is special about it, but I cannot export the binary mesh files as the anim refs seem to be corrupt for about half of the meshs. I'm not sure if this is stable enough to submit yet as I have absolutely no idea why it is doing this.
Also, I stuck the 50.8MB model through the exporter, I'm sorry to say that MaratisPlayer opened both binary version and xml version in ~9s. Interestingly, though, the bin is 979KB
I saw that it was added to Maratis, but I didn't see it being added to MaratisPlayer. Oh well
I think I've managed to make it add .mesh .maa and .mta files, but there didn't seem to be a MMaterialAnim::getNew() so I wasn't able to add .mma files. How can I create a new one to write temporary data to?
Tadaa! I have it saving the mesh files, and material files, to the npk!
What is strange is, I accidentally clicked on the published executable, without thinking that I would have had to add the bin loaders...
It worked...
I...
I don't know why it would just work...
Did you make it do magic Anael? I can't see the bin loaders added in the player at all.
Oh well. I will add them and do some testing at lunch tomorrow, then submit it probably. Am I ok submitting the VS2010 solution too?
I had a few issues with the "Demos" project, which for some reason kept giving me corrupt anim refs, but I'll see if I can figure out what that is.
I think I've very nearly almost got the mesh stuff working. For some reason, however, when I call destroy on a MWritablePackageFile, it decides to crash somewhere deep within the windows system, somehow tracing back to DispatchMessage. I guess I've probably trashed the stack somehow, but I'm not overly sure how. Gah! So close!
EDIT: ignore that. Just me overflowing a buffer... silly me...
Cool, well, I'm going to have to fall back to a slightly less than favourable method for writing to the package, unfortunately npk doesn't allow reading from a buffer (go figure...) so I can't just give it the binarised data, I will need to save it out to a temporary file first, I guess there's no reason in keeping the temporary files, so shall they just be deleted after publishing? Or do you see some reason why we might want to keep them around?
Thanks for the info, I will have a look at what possible options are.
If I create any generic behaviours, I will make sure to share them and upload where appropriate
I realise that I'm suggesting a load of different things and offering to take on a lot of these things... I hope you don't mind, I'm just trying to get a better feel for the engine and try to help where possible.
While looking at the options for GUI within Maratis, the 2 options seem to be doing it in 3D and rendering it in a separate render pass, or doing it in 2D, but hard coding the UI using MGui. The first thing that I noticed is that MGui isn't being built as a dynamic library. Is it possible to use MGui within a game application at all if it was changed to not being a static lib?
Secondly, are there any plans to make MGui data driven? I have done a _lot_ of UI work in my current job and the most tedious thing I have found is for a UI designer to make a mock up, for me to have implemented it, then they come and ask me to move something 5px to the right. It's reasonably bad in data, where I wouldn't have to recompile every time, but if it's in code, it would be even more fustrating. The other option, doing it in 3D, might be an option, but all the UI designers I have worked with are more comfortable in Photoshop and Flash than blender/max/maya/... With regards to there being no editor for MGui, that could fairly easily be fixed by creating a photoshop/gimp plugin. There already some photoshop ones that will export the layer information to xml and similar things for gimp
Of course, some 3D menus can look amazing, and this would always be an option, but there are usually things which are easier to do in 2D. Anyway, just wondering what the general thoughts about this would be. I have no UI design for my project at all right now, so I don't know what I will require, but it's a good idea for me to get an idea what sort of work is associated with each option (integrating a flash renderer for a main menu UI is still on the cards too)
As a side note. Is it possible to create child windows? If I'm going to go ahead with the profiler, it would be cool to have it give it's information in a pop-out window so you can see the information it produces.
Ok, cool I think I can work with that Thanks
EDIT: I had to mediate a family discussion at lunch time, so I didn't get time to finish this, however, I did manage to get the majority of the groundwork done to get this set up.
Ok if I submit this myself when this is done? I can't see why it would cause any problems with other OSs I can't test.
Oh, does the mesh loader automatically add the loaded mesh to the level? Ok, Well, I would have made a big mess if I wouldn't have realised that
I'll do the mesh saving at lunch today quickly then Doesn't look like much work at all
I had a quick fiddle with the package manager. I added the package key to the game plugin, the way I'm doing it at the moment is passing a c-string and then splitting it into substrings, then using a hash function to create up to 4 ints and store it as the tea key. As StartPlugin is called before attempting to load a package, or before publishing, that means the key will have been set. I'm not entirely happy about using the hash function yet. I can't think of a better plan right now though. Ideas?
Also, I had a look at how to save the mesh file. Should I just load every xml file again and then write it out again? As there are potentially multiple levels, I think it might be problematic to only save out the meshs loaded, right?
Maratis forum » Posts by Nistur
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 3 official extensions. Copyright © 2003–2009 PunBB.