I'm not too certain if SDL does this already, but I'm considering porting my in-development game from Cocoa to SDL ( mainly so I can have joystick control ) and right now I get fonts, textures, other data, etc via Cocoa NSBundle calls. That way I can package files in the bundle, in subdirs like Resources/Textures/*

Now, I'd like to be able to do the same in SDL -- ideally sticking with using the app bundle when on a Mac. But, how do I get the binary's location on disk? With Cocoa it's easy, but I can't think of any posix-friendly ways -- and I'm pretty certain I can't trust the current working directory.

Any ideas?

If you want to grab the posix path to your app's resource directory, do this: [[[NSBundle mainBundle]resourcePath]cString]; That returns a const char* with the full path to the bundle's resource folder. IIRC, that is.

SDL changes directory to the folder containing the app bundle on the mac (configurable by editing SDL_Main.m). On linux at least, you just gotta hardcode a location (like /usr/share/games/mycoolgame/). On windows, I think you'll find the CWD is the folder containing your application...

Fenris Wrote:[[[NSBundle mainBundle]resourcePath]cString];

As a sidenote, cString shouldn't be used. From NSString.h:

/* The "cString" methods are discouraged and will be deprecated in the near future. These methods use [NSString defaultCStringEncoding] as the encoding to convert to, which means the results depend on the user's language and potentially other settings. This might be appropriate in some cases, but often these methods are misused, resulting in issues when running in languages other then English. UTF8String in general is a much better choice when converting arbitrary NSStrings into 8-bit representations. */

Alex Diener

And for use as a file path, you should use -fileSystemRepresentation, which will use the appropriate encoding (currently UTF-8, but who knows about the future...)

OneSadCookie Wrote:And for use as a file path, you should use -fileSystemRepresentation, which will use the appropriate encoding (currently UTF-8, but who knows about the future...)

I appreciate the replies, but right now I'm using NSBundle to get the paths and it works. I was just wondering if there were any magic SDL functions that would do it in a cross platform way. You'd think there would be...

I guess what I'll do is just #ifdef for different platforms and stick with NSBundle on the mac and use CWD for windows and *shudder* hardcoding on linux.

Of course, I don't actually have linux or windows. This was really just a mental exercise and planning for the future.

For OSX and Linux, you use a basic Unixism: your app's parent directory is "." -- yes, a period. Thus, you'd refer to your game-data directory with "./Data". I'm sure that that will also work with Windows.

You can also walk a directory with opendir(), readdir(), and closedir(), all in dirent.h, if you wish to (say) list savegame files in a cross-platform manner.

TomorrowPlusX Wrote:I guess what I'll do is just #ifdef for different platforms and stick with NSBundle on the mac and use CWD for windows and *shudder* hardcoding on linux.

No need for #ifdef's - simply edit the appropriate lines in SDL_Main.m, which is mac specific anyway

lpetrich Wrote:For OSX and Linux, you use a basic Unixism: your app's parent directory is "." -- yes, a period. Thus, you'd refer to your game-data directory with "./Data". I'm sure that that will also work with Windows.

You can also walk a directory with opendir(), readdir(), and closedir(), all in dirent.h, if you wish to (say) list savegame files in a cross-platform manner.

Your app's working directory is "." For a Carbon/Cocoa app, it's the root directory, for a CLI tool, it's whatever directory it was called from, which is as on Unix.

Using CFBundle/NSBundle is the only way on the mac to find the app's directory with any certainty.

On Unix, you'd have to launch the app with a shell script which either sets an environment variable or makes sure the app is launched from the correct directory.

EDIT: PS: try not resurrect old threads older than a month or so, as those issues have most likely been resolved by now. If you feel like you have to say something, create a new thread and link to the old one.