In the case that you’d like to keep your resources in an external folder,
you can do what I sent you, but then add the line chdir("…/…/…/…/"); to
set the working directory a few directories higher. I don’t know if there
is a better way than this.
What I found to be the most portable was to have functions to return
path prefixes. The thing is, there can be many different places to put
things, it might not be just one place. For example, there is per-user
or system-wide stuff, platform-independent or platform-specific stuff,
etc… It helps to have a concept of “paths” (an ordered list of
different prefixes to try).
Then, on a platform like Mac OS X, you might have preferences in
~/Library/Preferences, saved games in ~/Library/Application\ Support,
image resources in /Content/Resources/… (which needs to
be obtained with a bit of code like that the previous poster gave)…
On Linux, the first two might both be ~/.mygamename (with a mkdir()
slipped in when files are opened for writing, to make things things
are all right), and the images be in /usr/share/mygamename (with the
"/usr/share" part taken from autoconf’s datadir macro at build time).
I like to have a small family of functions that return something like
an SDL_RWops*, say OpenDataFile(), OpenResourceFile(), etc… The
configuration file is something I often end up treating specially,
with a LoadConfig()/SaveConfig() pair that returns and takes a struct
with the configuration, and keep all the magic in there, since it’s
fairly specific from one platform to the other, if you want to play
nice (save as a property list on Mac OS X, store in the registry on
Windows, etc), but you can make it more generic too.
Not rocket science, but needs to be done…On Thu, May 22, 2008 at 1:58 PM, Holmes Futrell wrote: