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
Welcome among us and no, you're the first one to come with this question if I remember correctly!
Short answer, no. Long answer: there are a couple of work arounds and I'll add this option, it's a good idea.
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.
That is correct.
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.
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.
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.
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.
I'm looking forward to seeing what you will come with!
Btw, nice avatar! Brings back memories...
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?