Configuring the working directory

edited August 2010 in Help request
I'm pretty much a complete Orx rookie, and I'm sure this is a question that must have been asked before, but after searching the forums and Googling about, I still haven't found an answer.

Is there a way to specify, in the main game.ini config file, which working directory to use? My problem is as follows (I'm coding in Linux, using Eclipse).

${BASEFOLDER}/
..assets/
..Debug/
..Release/

When I compile the Debug version of the game, it goes (naturally) into the Debug/ folder, where I have MyGame_d.ini. Likewise for the Release version: into the Release/ folder, with MyGame.ini.

When I run the executable, all asset-loading seems to happen relative to the executable, so I'd have to say, for instance "Texture = ../assets/mytexture.png". This happens regardless of whether I'm in the Debug/ directory (running ./MyGame) or one level above (running ./Debug/MyGame).

Now, when I want people to download the game, I'll have the executable in the *same* directory as assets/. That is, I'll load textures with "Texture = assets/mytexture.png". To do use this structure while I'm just coding (i.e., without the "../" prefix), I'd have to copy all of my asset tree into each of the Debug/ and Release/ directories, which seems a waste to me.

Is there a way I can specify, in MyGame_d.ini or MyGame.ini, where all subsequent loads will come from? Something like:
PathRelativeToExe = ../
...so that both my Debug/ and Release/ apps will load "../assets/mytexture.png"

Which I can then change, when publishing, with just one line:
PathRelativeToExe = ./
...so that the app will load "./assets/mytexture.png"

Sorry again if it's been asked before. And thanks for any help you can give.

Comments

  • edited August 2010
    newton64 wrote:
    I'm pretty much a complete Orx rookie, and I'm sure this is a question that must have been asked before, but after searching the forums and Googling about, I still haven't found an answer.

    Welcome among us and no, you're the first one to come with this question if I remember correctly! =)
    Is there a way to specify, in the main game.ini config file, which working directory to use? My problem is as follows (I'm coding in Linux, using Eclipse).

    ${BASEFOLDER}/
    ..assets/
    ..Debug/
    ..Release/

    Short answer, no. Long answer: there are a couple of work arounds and I'll add this option, it's a good idea. =)
    When I compile the Debug version of the game, it goes (naturally) into the Debug/ folder, where I have MyGame_d.ini. Likewise for the Release version: into the Release/ folder, with MyGame.ini.

    Sounds good to me. If you haven't already done so, I'd suggest to keep both files almost empty, including another one (in ../, like this @../MyGame.ini@, for example) that will contain all the common config info, so as to prevent from duplicating things between Debug/MyGame_d.ini and Release/MyGame.ini.
    When I run the executable, all asset-loading seems to happen relative to the executable, so I'd have to say, for instance "Texture = ../assets/mytexture.png". This happens regardless of whether I'm in the Debug/ directory (running ./MyGame) or one level above (running ./Debug/MyGame).

    That is correct.
    Now, when I want people to download the game, I'll have the executable in the *same* directory as assets/. That is, I'll load textures with "Texture = assets/mytexture.png". To do use this structure while I'm just coding (i.e., without the "../" prefix), I'd have to copy all of my asset tree into each of the Debug/ and Release/ directories, which seems a waste to me.

    Which makes perfect sense, actually. I never personnally encountered this issue as my directory structure usually contains a /bin, so all my data still have the ../ prefix.
    Is there a way I can specify, in MyGame_d.ini or MyGame.ini, where all subsequent loads will come from? Something like:
    PathRelativeToExe = ../
    ...so that both my Debug/ and Release/ apps will load "../assets/mytexture.png"

    Which I can then change, when publishing, with just one line:
    PathRelativeToExe = ./
    ...so that the app will load "./assets/mytexture.png"

    I could add a WorkingDirectory config parameter, this way you could have WorkingDirectory = ./ in your ../assets/MyGame.ini that would be overridden in your Debug/MyGame_d.ini and Release/MyGame.ini. Something like this:

    @../MyGame.ini@ <= This will load everything from your "retail" version.

    WorkingDirectory = ../; <= This overrides the "retail" version for this current production one.

    This way you don't even have to change a single line of config when releasing your game. When launching MyGame.exe from the base directory, it will use the base MyGame.ini and no overrides will occur.
    Sorry again if it's been asked before. And thanks for any help you can give.

    It wasn't and even if it were there's no trouble! =)

    So now, for the work arounds.

    Right now, in your init callback you can simply change the working directory with the chdir() C function. It's not very glamour but it should work nicely till I have the WorkingDirectory config param (that will just do a chdir() behind the scene anyway).

    Actually, as it's the simplest work around, I won't even go with more complex/annoying one.

    I'm still not sure how I'll add the WorkingDirectory config param, as obviously it should take place *after* all the config includes have been done, or there'll be a big discrepency depending on where you define/override it when using multiple config files. It should also not affect the iPhone version, as you can only read and write in some predefined directories that can't be changed.

    I'll think more about it, but in the meantime, chdir() in the Init callback of your game should just work fine. =)

    EDIT: An other option would be to introduce a concatenation operator in the config system. This way you can concatenate path as you want, where you want and even completely change your directory structure.

    The last option, which I've been thinking about for quite some time now, is to finally add the package module that allows defining as many entry points as you want and map them as you see fit. Using physFS for a package plugin would even allow to pack all your assets in archives for release, whereas you would be able to use scattered files during the production phase.

    I've been very close to implement this, but some of the plugins wouldn't be compatible with it. I'd have to change stb_vorbis (which is pretty easy) but SFML would unsurprisingly be the annoying one, particularly for streamed sound files.

    It wouldn't exist on iPhone, though, due to the fixed folder hierarchy, the Core API and performance impacts.
  • edited August 2010
    Wow, thanks for the thorough response! I wasn't expecting something so organised.

    I think it'll end up being either simply creating the bin/ directory (thus making all versions work with the ../ prefix), or, as you say, calling chdir() in the Init() function. Good and simple fixes, which honestly I should have thought of earlier. I'm just stuck in my programming ways, sometimes.

    Thanks again for the detailed help. Hopefully I'll have something interesting to showcase in the not-too-distant future.
  • edited August 2010
    You're welcome. Don't hesitate if you have any other question, I'm sure someone will answer, usually within a day. Orx has many particularities and they are not always easy to figure out.

    I'm looking forward to seeing what you will come with!

    Btw, nice avatar! Brings back memories...
  • edited August 2010
    iarwain wrote:
    I'm still not sure how I'll add the WorkingDirectory config param, as obviously it should take place *after* all the config includes have been done, or there'll be a big discrepency depending on where you define/override it when using multiple config files.

    One way could be to have different config params for different types, one for sound-files, one for textures, etc. But maybe that's even more work?
  • edited August 2010
    That could be an option. I'm afraid it'd get too confusing to use. But maybe it's the best trade off. I'll think more about it! =)
Sign In or Register to comment.