Search options (Page 17 of 18)

Anael - Yes, I think I had that one too, I think it doesn't like the UTF-8 character in your name, and there was no encoding specified before it or something to that effect.

zester - No problem. Took me a little while of fiddling to get it compiling, no sense in anyone else doing the same

Ok, so there are a couple of SConscript files that need 'X11' adding to them ie:
env_local.AppendUnique(LIBS = ['GL',
                                                             'Xxf86vm',
                                                             'X11'])
MSDK/MGui/SConscript
Maratis/Editor/SConscript
Maratis/Player/SConscript
Examples/ManualUse/SConscript

Also, the editor and player need 'dl' adding to the same list.

Hope that helped. Not sure why, but it compiles fine on one of my machines without it, but one it needs the extra libs.

I was actually wondering if iOS was the problem. To be honest, I don't know exactly how iOS treats files in the IPA, what path it expects for them, of course, there's no reason why we should change directory on iOS at all, so we can ignore that, the package can be loaded relatively and all files within that will be using relative paths. Regardless, as you say, it can be changed later. I will strip the path down for packaged files and load them like that.

I will also take a look at the font loading again and make sure that it works properly.
Almost there.

Right, I put the code in for lua, and while debugging it, I realised something. I had for some reason been assuming that the paths I was being given were all relative to the project file. Silly me. Well, I have lua working now, but I have to somehow extract the relative path from it.
I think I have 2 choices. The first is to either change directories to the project directory and have all the data files attempt to load from there. The second is, when loading the files using the wrappers, strip the project directory off the beginning first, try to load that, then, if that fails, revert to the full path.

The second option seems a bit hacky. I'm just not sure where to begin with removing the need for absolute paths. I will have a quick looksee tonight, but I think I'm going to call it a night soon. I may have time to sort it during my lunch break tomorrow, which would leave tomorrow evening to try and write the MPackageFile stuff. Sounds like a challenge

(also, I realise that noone is setting this deadline for me but myself)

EDIT: I really don't know what to do right now. The editor expects to be run from it's own directory, so looks for the gui elements within that directory. I'm not sure now if I should change that. Seems like a pretty big change in design :S

Sure, I had a quick look at it and it doesn't seem like it will be much of a problem.

for the wrappers, I've put them in MFileTools.{h,cpp} and named them M_fopen M_fclose etc. They return MFile* which currently is a base class that handles stdio, but I also have a MFileOpenHook interface which, if a hook is specified, will allow loading from wherever, as long as it returns an MFile* (or inherited class)

I have a skeleton MPackageManager in MEngine which, when initialised, registers it's own MPackageFileOpenHook. The MPackageFile's haven't been written yet, but the plan is to cycle through the loaded packages (even though I'm only going to load one for now, based on the project name) and look for entities in it with the name requested. If they all fall through, it will revert to the MFile behaviour.

I figured MEngine was the correct place to put the package manager as it didn't really contain core functionality, but file I/O itself did. Also, regarding the MFileOpenHook class, as the package manager is in, basically the layer above MCore, seemed sensible to have a generic callback class. Also, as a few people seem to have been talking about a web player, if this ever gets implemented, being able to replace MPackageFileOpenHook with MStreamFileOpenHook should be easy.

Just checking that this design is acceptable before I finish it off. It's still fairly easy to move it around if you're unhappy with anything. I am aiming to submit the basic package code on Saturday, along with instructions on how to create packages manually (as there won't be a publish button yet) and any other useful pieces of information. Then, if I can work out how MGui works (as of yet, I haven't managed to find any data as to how it displays...) then I can try to add the publish button, and make the package... possibly by the end of the weekend.

Actually, that's a point, do you have any preference as to how I specify which files go into a package? I can just add all the subdirectories of the project, but that would quite possibly add source files and raw data, depending on how people's projects are layed out. Maybe another xml file?

That's what I thought too. I was just playing with the idea of python build scripts because it would add to the flexibility. But I guess that if people have need to change the publishing system in any way, the chances are they will be willing to change code.

I don't think we need to write either. I guess if a file is attempted to open writable, I will try to load it from OS, which would solve the problem of save files as it wouldn't even consider putting them into the package.

I am enjoying working on this and getting to know the engine, so the commitment is no issue I will, however, have to start doing some more work on my own game project soon, otherwise I'll get caught up in this and my game won't move ahead I am going to try and get this done to an acceptable (albeit maybe quite basic) standard by this weekend, after that I will be focussing mostly on my game, just doing fixes to the package stuff when needed. Once my project is rolling along, I can see if there's anything else I can help with

Research is done. Design is planned. Wrappers are now written.
Task list as follows:
- (probably for lunch during work tomorrow) Replace stdio fopen/fclose/fread/... with new wrappers and test.
- make a test npk manually and get it loaded into the app.
- search npk for files before attempting to load from OS
- ensure fopen, fseek, ftell, fread, fclose all work with package files (no writing using standard file I/O?)
- Add packaging functionality to MaratisEditor. Not sure if this should just add the whole directory.
- Put a publish button into MaratisEditor GUI and create a framework for publishing, including data packaging stage

I hope that I can get the basic reading functionality working by the end of the weekend. With regards to the publishing, is it best to do this in code, or by using python scripts do you think?

I've been able to use scons on my work machine. I think it might be a limitation of VC++ Express that I can't use it at home.

I have something working at least. It's not important. I just thought I would write my findings in case other people had problems with it.

I fully understand. I just started working on it under the naive assumption that iOS had a sensible API recompiling libc for the sake of that does seem like a bad idea.

Writing the wrappers should be fairly easy and I will look at what lua needs.

EDIT: I've just walked home, thinking about this. I'm pretty sure that, with my luck, I will decide to use some library which will cause problems. So I will do the function wrappers first, and then add the patches, but wrap them in #ifdef M_PATCH_FILE_IO. If I get permission from my work to do some iOS stuff and I splash out to get myself a Mac to do some dev work on, I will look into creating a patched libc. But initially. everything will use wrappers and the patch code won't even be compiled (unless users are feeling brave and/or stupid).

EDIT EDIT: I was also thinking, not that you should replace it now, because you have your xml exporter etc, but have you looked at google's protobuf? It has some nice features including automatic binarisation.

Even if there are better programmers out there, you're the owner and architect. It's your vision.

I've been having a look around and I'm not sure than vm_write is available on the iOS SDK. Which is just great. People suggest that ptrace might work. If I had a Mac here I'd prod around in the iOS SDK and see what's available, but people are using the work Macs... From what I can see though, you should be able to modify the memory within your own application, as long as it doesn't do anything else to violate the developer agreement, should be allowed. I'll try and remember an apple ID so I can read through the developer agreement later.

EDIT: I had a look and it doesn't seem to allow it. Technically there might be some way to hack it to unlock the memory and write it manually, but that seems like an insanely stupid idea. That sucks. Hmmm. Technically you _could_ just not link in -lc and compile something like uclibc into Maratis without file I/O stuff, but that seems a lot like overkill. Plus I'm not sure if that would be allowed either.