Hello you all, I''ve got a little (dumb, indeed...) question. I''m making a game on Linux (Slackware - KDevelop) using SDL. I want to load a BMP on a surface, well fairly easy: SDL_Surface *mySurf = LoadBMP("/home/file.bmp"); This will do fine, but I want my project to be portable! I just cant figure out how to work with paths on Linux (Just like in VB - using app.path). What should I do? Thanks in advance

The easiest solution is to have your application use pathes that are relative to the current working directory. Your executable(s) would be placed in a directory named bin in /usr/lib/app-name. The default executable (the one in the user's PATH, e.g., /usr/bin or /usr/local/bin) would be a script that changes the current working directory to that directory, and then runs the executable that it corresponds to (bin/app-name, for example).

Inside of /usr/lib/app-name you could place subdirectories or symlinks to root-based directories (/usr/lib/app-name/data could point to /usr/share/app-name for example). Then your application would access files with something/file.abc (to base upon my last example: data/file.abc).

This is what many *nix applications do, and it's the easiest way that doesn't involve any configuration files or work on your part that I can think of.

Edit: made my examples nicer .



[edited by - Null and Void on April 8, 2003 10:30:32 PM]

If you want to get the path you can always use the first string in the second parameter of main:




argv[0] contains the complete path of the executeable so if the program was in "/home/username/app/" and was called "path" argv[0] would contain: "/home/username/app/path" so you can just do some string manipulation to find the path of the directory.

quote: Original post by YoshiN
argv[0] contains the complete path of the executeable so if the program was in "/home/username/app/" and was called "path" argv[0] would contain: "/home/username/app/path" so you can just do some string manipulation to find the path of the directory.

Errm... no it doesn't. argv[0] contains whatever the program was invoked as, and might not contain any directory info at all. However, relative directory operations performed by a program are treated as relative to the actual location of the executable (not sure what happens with symbolic links). So if your program was in "/usr/local/games/foobar/bin/baz", and you opened the file "../data/myfile.dat", you would end up opening "/usr/local/games/foobar/data/myfile.dat". So in general, you just don't have to worry about; use relative paths (ones that don't start with /).

How appropriate. You fight like a cow.

[edited by - sneftel on April 8, 2003 9:20:40 PM]

hum, well... sort of all this

about what Null & Void and Snetfel said...
The function I''m using is SDL_LoadBMP - definetely it doesnt accep any relative path. This was the first thing I tried ("./Img/Bg.bmp") but the surface was null...

Yoshin, you gave me a idea...
isn''t char *argv[] the commandline? if it is, there''s no problem

I now remembered that I once saw something similar, I think it was a rewrote of MS-DOS''s TYPE command...

SDL WILL use relative paths.

Remember that if you''re running your program from an IDE, its "working directory" may be different from what it would normally be. Make a program that creates a file in the current directory, to figure out where you''re looking.

How appropriate. You fight like a cow.

argv[0] is never guaranteed to contain any kind of useful path.

Linux programs use one of three solutions (not necessarily mutually exclusive):

1) use a starter script, which does a "cd" to the actual install location, and starts the real binary. The starter script is written during install. Then get everything relative.

2) use a search path from an environment variable, with possible "standard" directories tacked on or used if the env var is not set.

3) compile the install location into the binary (only works when shipping source :-)

sneftel is wrong, by the way. Relative paths are relative to the current working directory of the process. By default, the current working directory is inherited from the invoking shell.

Perhaps some desktop/gui shells set the working directory to the directory of the app when they start the app, but I wouldn''t bet on it.

Grrr Snetfel, you''re all right, but it does works as supposed only when ran from konsole... running it from nautilus and I''ll get my old black screen of the null surface :D

hey BTW does this work for windows too? (relative paths ./ etc...)

that''s it Anonymous - no bet on those :D
However I think that the most appropriate thing to do is to force the player to start my game from the terminal. This way I can take advantage of using printf() for immediate debug output