SFML community forums
Help => Graphics => Topic started by: Xavura on February 18, 2009, 04:27:12 pm
-
I am unable to load an image from file, I think it's because I'm not putting it in the right place but I've tried EVERYWHERE. I've even tried it with absolute paths to the image but that caused all kinds of errors.
I'm using Visual Studio C++ 2008 Express Edition. I've tried putting the .BMPs in "Resource Files", in the Project's directory etc. plus I've tried JPGs and PNGs as well.
The error is "Failed to load image .... Reason: Unable to open file".
I'm not sure if that means unable to OPEN or unable to LOCATE, either way I'm lost.
:?
-
Hm... What are you expecting with your question? The sf::Image::LoadFromFile() function works fine. Did you put an image file into your project directory itsself (not the release/debug folders, but where the VCPROJ file is located)? And did your path in the code exactly match the file's path?
Perhaps, a little code snippet might help...
-
Like I said before, I have tried putting it in every possible place... I just tried putting it with the .vcproj file to no avail.
I've had Input, Event, Clock, Window and RenderWindow all working fine it's just this that refuses to work.
... the code is pretty much:
#headers go here ...
int main() {
using namespace sf;
using namespace std;
Image grassBitmap;
if (grassBitmap.LoadFromFile('grass.bmp')) {
cout << "Loaded bitmap." << endl;
}
else {
cout << "Unable to load bitmap." << endl;
}
cin.clear();
cin.ignore(255, '\n');
cin.get();
return 0;
}
Output:
Failed to load image "grass.bmp". Reason : Unable to open file
Unable to load bitmap.
-
Are there really the ' instead of the " characters?
if (grassBitmap.LoadFromFile('grass.bmp'))
And grass.bmp is in the project directory?
-
- Don't import a namespace inside a function definition.
- Use double-quotes for strings, not single-quotes (:arrow: "grass.bmp").
- Double-check paths. Use an absolute path for testing, like C:\grass.bmp, and put the file there.
-
No, they are actually quotation marks like > " I'm just used to using apostrophes. :lol:
... and if by project directory you mean:
C:\Documents and Settings\Xavura\My Documents\Visual Studio 2008\Projects\SMFLTest\SMFLTest\HERE
... then yes.
-
- Don't import a namespace inside a function definition.
I don't like to empty namespaces at all, but I think it's better to keep the specifications as local as possible (especially using namespace in headers is evil).
-
C:\Documents and Settings\Xavura\My Documents\Visual Studio 2008\Projects\SMFLTest\SMFLTest\HERE
You could try the superior directory.
An absolute path (simple as Tank stated) didn't work?
-
- Don't import a namespace inside a function definition.
- Use double-quotes for strings, not single-quotes (:arrow: "grass.bmp").
- Double-check paths. Use an absolute path for testing, like C:\grass.bmp, and put the file there.
I'm really new to C++ but the tutorials I have been following usually import namespaces inside functions. Is there any reason not to?
Say if function a uses std and function b doesn't, then it makes more sense to import std for function a only rather than globally for the entire file?
I did use " in the actual file, just ' when I posted on the forum.
I'll check the paths and try an absolute path but last time I tried that I got access violations/exceptions.
Thanks for the help so far.
-
Using an absolute path causes something like this to happen:
Unhandled exception at 0x102565af in SMFLTest.exe: 0xC0000005: Access violation reading location 0xcccccccc.
I'll try putting them in other locations but ... as stated twice, I have already tried every possible location.
-
I'm really new to C++ but the tutorials I have been following usually import namespaces inside functions. Is there any reason not to?
Say if function a uses std and function b doesn't, then it makes more sense to import std for function a only rather than globally for the entire file?
No, as I said, it's good practice to keep the using namespace as local as possible or better to avoid it completely. That's similar to variable declarations: You don't declare something globally if you need it only in one function.
Your problem seems to be anywhere else. Did you use the debugger to find out where the access violation occured (in debug mode)? The adress indicates an uninitialized variable.
If nothing helps, recompile SFML, possibly something went wrong.
-
No, as I said, it's good practice to keep the using namespace as local as possible or better to avoid it completely. That's similar to variable declarations: You don't declare something globally if you need it only in one function.
Your problem seems to be anywhere else. Did you use the debugger to find out where the access violation occured?
If nothing helps, recompile SFML, possibly something went wrong.
The debugger is pointing to the line with the call to LoadFromFile() (only when using an absolute path).
Recompile? I downloaded the headers/libraries like the tutorial says to. Was I supposed to do something else?
-
Nah, importing namespaces is not comparible with defining variables. It's something that happens at compile-time, not run-time.
If you ever want to maximize your compilation times, then yeah, you'll be fine importing in functions, where you need the imports. ;)
Basically, my opinion is to use imports as less as possible. It even makes your code clearer, because you can see where types and other things belong to. Also imagine Laurent wouldn't use CamelCase for classnames. You'd have a perfect nameclash with sf::string and std::string, for example. The only reason why people import is to write less code. But I think that's not really an advantage. C++ invented namespaces, don't throw them away, again! ;)
-
The debugger is pointing to the line with the call to LoadFromFile() (only when using an absolute path).
Maybe a dumb question, but are you escaping the \ characters (if used at all)?
-
Nah, importing namespaces is not comparible with defining variables. It's something that happens at compile-time, not run-time.
If you ever want to maximize your compilation times, then yeah, you'll be fine importing in functions, where you need the imports. ;)
Basically, my opinion is to use imports as less as possible. It even makes your code clearer, because you can see where types and other things belong to. Also imagine Laurent wouldn't use CamelCase for classnames. You'd have a perfect nameclash with sf::string and std::string, for example. The only reason why people import is to write less code. But I think that's not really an advantage. C++ invented namespaces, don't throw them away, again! ;)
Thanks for the information, 'tis handy to know and I agree that writing less code isn't that much of an advantage.
Do you have anything to say regarding my problem because you seem to be knowledgeable enough.
-
The debugger is pointing to the line with the call to LoadFromFile() (only when using an absolute path).
Maybe a dumb question, but are you escaping the \ characters (if used at all)?
:shock:
Like... double backslashes?
No. :x Please don't tell me that's the problem...
I'll try now.
EDIT:
Doesn't make a difference:
// ...
if (grassImage.LoadFromFile("C:\\Documents and Settings\\Xavura\\My Documents\\Visual Studio 2008\\Projects\\SMFLTest\\grass.bmp")) {
cout << "Worked." << endl;
}
else {
cout << "Didn't work." << endl;
}
// ...
Unhandled exception at 0x102565af in SMFLTest.exe: 0xC0000005: Access violation reading location 0xcccccccc.
-
Yeah, exactly. "C:\blah.bmp" must be "C:\\blah.bmp". Please turn on your compiler warning completely. It should tell you that you've used an unknown escape sequence -- at least in the most cases. When using "C:\n..." or "C:\t..." or something else that's really defined, you're trapped. :P
I recommend to use slahes instead of backslashes. They work flawlessly on Windows, too.
Edit: Are you linking to the correct libraries? When building your program in debug mode, you have to use the debug libraries of SFML. (sfml-graphics-d.lib etc.). Are you linking dynamically? Then please define the SFML_DYNAMIC preprocessor macro.
-
In Project Properties > Configuration > Linker > Input > Additional Dependencies I have:
sfml-window-s.lib
sfml-graphics-s.lib
sfml-system-s.lib
sfml-audio-s.lib
EDIT:
I've tried changing them to the -s-d.lib variants and I get a LOT of errors. Changing them to the variants without suffixes also generates errors.
-
Without a suffix, you link dynamically and therefore need to #define SFML_DYNAMIC in your project properties.
If all of that doesn't work, I don't have a clue what's wrong.
-
I have defined SFML_DYNAMIC in Project Properties > Configuration > C/C++ > Preprocessor > Prepocessor Definitions.
Upon compiling I receive just one error:
mt.exe : general error c101008a: Failed to save the updated manifest to the file ".\Debug\SMFLTest.exe.embed.manifest". The parameter is incorrect.
Any ideas?
-
VC++2008 screwed up? ;) Sorry, I don't know, I don't use MSVC.
-
have you tried running the exe on its own with the image in the same dir as the exe? sometimes, if its a path problem, it'll work. I also recommend using slashes instead of backslashes.
Also, if you're using SFML_DYNAMIC, then you dont need to link to the static libs right? (so sfml-window-s.lib should just be sfml-window.lib).
-
Nah, importing namespaces is not comparible with defining variables. It's something that happens at compile-time, not run-time.
I think I know the difference. I also wrote "similar" instead of "exactly the same in every respect", and of course that was referred to the context I told it in. :roll:
As I already stated, the address 0xcccccccc may indicate an uninitialized variable. Maybe you link the wrong libraries of SFML or the wrong CRT configuration. By the way, did you try rebuilding the solution (concerning your manifest error)?
-
I think I know the difference. I also wrote "similar" instead of "exactly the same in every respect", and of course that was referred to the context I told it in. :roll:
Of course you know the difference. My post shouldn't mean that I think you don't. The only thing is that even in that context, it was misleading. Local variables make sense, everytime. Now imagine you import namespaces everytime locally in functions. Do you think the compiler would like that, since it means shitloads of extra-work? ;)
Whatever, I guess we all agree that importing namespaces is a big no-no. Could be compared with using global variables. ;)
-
Hi,
just wanted to let you know that I have exactly the same problem with LoadFromFile(). The interesting thing is that the programm compiles perfectly fine and the errror occours only at runtime (even when I run the most basic tutorial program LoadFromfile() crashes). Everything else works normally ....
The problem can't be that LoadFromFile() doesn't find the image, since then it would just return false and not crash the whole compiler.
I'm pretty sure that the problems started when I switched from VS2003 to VS2005, but that might be just an coincidense.
Realy hope somebody can help.... :cry:
-
It seems to be a problem with VC then. I would just encourage you to use another (better? ;)) compiler, but that's maybe not what you want to hear. :) Can you create a ZIP containing a minimal example, including an image?