Hello All,
I’m running into a stupid problem. I have a game written in C with SDL. I’m
also using SDL_image.
On Linux, it all runs fine. On windows, it runs fine if I execute it from the
directory I installed it to. But if I try to use a link (say from the start
menu) it fails to load the images which are either in the same directory, or in
a child directory.
I know it should be possible to do this, but I am at a loss. I did the
mandatory Google searches and unless I’m wording it wrong, I was unable to find
anything helpful.
I’m certain others have run into this. Could someone either help or point me in
the right direction?
Thanks!
Micah
Micah Brening <micah.brening gmail.com> writes:
Hello All,
I’m running into a stupid problem. I have a game written in C with SDL. I’m
also using SDL_image.
On Linux, it all runs fine. On windows, it runs fine if I execute it from
the
directory I installed it to. But if I try to use a link (say from the start
menu) it fails to load the images which are either in the same directory, or
in
a child directory.
Thanks!
Micah
Ok, so the mystery deepens.
I ran some basic tests. simple initalization, set video mode, and load a png
in the same directory as the executable. That worked. Even with a link in
the start menu.
So now I have two different questions. Is there something that would make the
executable think it was in a different directory than where it really is? And
second, is there a simple way of getting the current working directory that
the executable THINKS it is running from?
Sorry if this is a beginner question.
Thanks for any assistance!
Micah
I’ve been wrestling with a similar problem in another API, though the API itself shouldn’t be the source of the problem. The question I have for you is, is the problem arising when you’re running the program from the compiler in debug mode? If so, the current directory may be considered to be either the compiler’s home directory or the directory of the base of the solution/project.
At the very least check your link and see if there’s an option to place a Start-in directory as the same directory as your executable.–
Lilith
On 1/4/2008 at 8:50 AM, Micah Brening <micah.brening at gmail.com> wrote:
Micah Brening <micah.brening gmail.com> writes:
Hello All,
I’m running into a stupid problem. I have a game written in C with SDL.
I’m
also using SDL_image.
On Linux, it all runs fine. On windows, it runs fine if I execute it from
the
directory I installed it to. But if I try to use a link (say from the start
menu) it fails to load the images which are either in the same directory, or
in
a child directory.
Thanks!
Micah
Ok, so the mystery deepens.
I ran some basic tests. simple initalization, set video mode, and load a
png
in the same directory as the executable. That worked. Even with a link in
the start menu.
So now I have two different questions. Is there something that would make
the
executable think it was in a different directory than where it really is?
And
second, is there a simple way of getting the current working directory that
the executable THINKS it is running from?
Sorry if this is a beginner question.
Thanks for any assistance!
Micah
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Micah Brening <micah.brening gmail.com> writes:
Sorry if this is a beginner question.
Thanks for any assistance!
Micah
Alright, not only was it a beginner question, but it turns out it wasn’t even
SDL’s fault. Apparently, when you use NSIS to create a shortcut, you have to
have the $OUTPATH still set to where the executable runs from or else it will
run the Executable from the wrong dir.
It is the “Start In” part of the shortcut that caused the problems. Lilith,
you were right. Thanks for the heads up on that.
So, if anyone else had the same problem, that is the solution.
Sorry for the ignorant posts.
Mr. Lantinga and group, keep up the good work on this awesome piece of
software!
Micah Brening wrote:
So, if anyone else had the same problem, that is the solution.
I doubt it - what you’re doing now looks to me like your application
would only work when launched using that specific shortcut created by
your installer, not when launched with an arbitrary current directory
(e.g. from the command line).
It looks like you’re using hardcoded relative paths to locate your
resource files? Don’t. You can’t rely on having a particular current
directory when your applications starts, neither on Windows nor anywhere
else. On Windows, you can use GetModuleFileName() to find out where the
application is, on Mac OS [[NSBundle mainBundle] resourcePath].
-Christian
You also might take a look at PhysFS which already does the hard work.
-EricOn 1/4/08, Christian Walther wrote:
Micah Brening wrote:
So, if anyone else had the same problem, that is the solution.
I doubt it - what you’re doing now looks to me like your application
would only work when launched using that specific shortcut created by
your installer, not when launched with an arbitrary current directory
(e.g. from the command line).
It looks like you’re using hardcoded relative paths to locate your
resource files? Don’t. You can’t rely on having a particular current
directory when your applications starts, neither on Windows nor anywhere
else. On Windows, you can use GetModuleFileName() to find out where the
application is, on Mac OS [[NSBundle mainBundle] resourcePath].
-Christian
E. Wing <ewmailing gmail.com> writes:
Micah Brening wrote:
So, if anyone else had the same problem, that is the solution.
I doubt it - what you’re doing now looks to me like your application
would only work when launched using that specific shortcut created by
your installer, not when launched with an arbitrary current directory
(e.g. from the command line).
It looks like you’re using hardcoded relative paths to locate your
resource files? Don’t. You can’t rely on having a particular current
directory when your applications starts, neither on Windows nor anywhere
else. On Windows, you can use GetModuleFileName() to find out where the
application is, on Mac OS [[NSBundle mainBundle] resourcePath].
-Christian
You also might take a look at PhysFS which already does the hard work.
-Eric
So would you not say that if it is working now, it should (generally speaking)
always work?
I agree that I should use PhysFS for this, if nothing else, so I can compress
the images and sounds.
So PhysFS will find out where the EXE is located and when I give it a relative
path, it will figure out the full path?
If so, then I almost think it should be another SDL addon, like SDL_fs or
something because it seems very important to have.
Until then, I’ll look more into PhysFS.
Anyway, thanks for the Advice guys!
Micah> On 1/4/08, Christian Walther <cwalther gmx.ch> wrote:
Hello All,
I’m running into a stupid problem. I have a game written in C with SDL. I’m
also using SDL_image.
On Linux, it all runs fine. On windows, it runs fine if I execute it from the
directory I installed it to. But if I try to use a link (say from the start
menu) it fails to load the images which are either in the same directory, or in
a child directory.
Look in the link-properties, especially the entry for the working-dir (I
think thats would be the name in englisch Windows). That must be the same
where your exe is located. If you use an installer out of the box, that
could be the problem, there are some that leave that field blank, that was
the problem with one aof my first projects. It was Delphi, nothing big, but
I had that problem with the working dir. Could be it is the same with you
but has not to be.
HTH
NorbertAm Thu, 3 Jan 2008 18:39:19 +0000 (UTC) schrieb Micah Brening:
Micah Brening <micah.brening gmail.com> writes:
Until then, I’ll look more into PhysFS.
Anyway, thanks for the Advice guys!
Micah
Turns out the newest version uses CMake which is not playing nice with
mingw/msys at all. Yet another reason to make a SDL_fs using the same build
method as SDL. But, this is the SDL newsfeed, not one for Physfs, so I’ll keep
my complaining to myself.
Anyway, Thanks for all the help!
Micah
Micah Brening wrote:
So would you not say that if it is working now, it should (generally speaking)
always work?
(I assume you’re talking to me.) Well, I don’t know what exactly you’re
doing, and I’m not a Windows expert, but if by “it is working now” you
mean “the application works when launched using the shortcut created by
the installer” and by “always work” you mean “the application works when
launched in any possible way”, then yes, judging from what you said in
previous posts, I challenge that assertion.
Just try it: open a command prompt, cd to some arbitrary directory, drag
the application into the window to enter its path, and press return - if
it works, no matter what directory you were in, then good (and I’m wrong).
-Christian
Christian Walther <cwalther gmx.ch> writes:
Just try it: open a command prompt, cd to some arbitrary directory, drag
the application into the window to enter its path, and press return - if
it works, no matter what directory you were in, then good (and I’m wrong).
-Christian
Sorry, yes, I was talking to you, Christian. I should have mentioned that.
Command Prompt idea: naturally, it crashed, no error given. The problem I have
with hard coding the full path into the EXE is that people will install it to
different places.
So, the way I see it, I have two options. Have the installer plop a .ini file
with the path used in the install, and the exe pull it and use it. Or, as was
posted earlier, use Physfs (1.1.0 since 1.1.1 uses cmake)
Physfs, as long as it works the way I need, seems the better way to go.
But the test you had me do will be a way I continue to test my software to
ensure stability and flexibility. Thank you.
-Micah
E. Wing <ewmailing gmail.com> writes:
Micah Brening wrote:
So, if anyone else had the same problem, that is the solution.
I doubt it - what you’re doing now looks to me like your application
would only work when launched using that specific shortcut created by
your installer, not when launched with an arbitrary current directory
(e.g. from the command line).
It looks like you’re using hardcoded relative paths to locate your
resource files? Don’t. You can’t rely on having a particular current
directory when your applications starts, neither on Windows nor anywhere
else. On Windows, you can use GetModuleFileName() to find out where the
application is, on Mac OS [[NSBundle mainBundle] resourcePath].
-Christian
You also might take a look at PhysFS which already does the hard work.
-Eric
After toying with it, and being forced to use an older version of Physfs, I
found even it fails Christian’s test of running it in a consol that is in the
wrong dir.
It runs the program just fine, loads the DLLs just fine, but fails to find the
zip file.
But, all in all, I’m satisfied with the answer I found.
So thanks everyone for their assistance.
-Micah> On 1/4/08, Christian Walther <cwalther gmx.ch> wrote: