I'm trying to load an sf::Texture, but every time I run the program, my computer starts beeping (no joke), and the command prompt outputs a bunch of characters that look like ancient Egyptian hieroglyphics.
Relevant code:
#pragma once
#include "SFML/Graphics.hpp"
class TextureLoader {
public:
sf::Texture runway;
~TextureLoader(){}
TextureLoader() {
runway.loadFromFile("Runway.png");
}
};
Runway.png does exist, because I've tested creating an ifstream and it loads the image fine.
The debugger complains of an "Access violation reading location", but the location changes each time and I've never been able to find the memory space it points to in the debugger. Every object appears to be fine except for the texture.
You are mixing debug/release version of SFML libraries with your program's debug/release version. If your program is debug, use debug libraries of SFML, if your program is in release version, use release version of SFML.
People who are still figuring out how to set the project settings, please do as follows (note the "-d" for debug):
Related
I am trying to get a graphical representation of a chess-board with SFML 2.0. The problem is that I simply cannot load a texture, the command loadFromFile does not work and I don't know why. I already searched the web, also here in Stack Overflow but I did not find a solution.
What I did right now:
Setting all the dependencies for includes and libraries, .dll's and .libs
Changing text format from unicode to multibyte.
Copying the .dll's into the working folder (there was an error that visual studio couldnt find the dlls even though I linked them in the project)
Using the whole path for the image file
using the LoadFile-command with 2 arguments (even though the second one is optional I guess)
Changing runtime library from MDd to MD (trying to get it work in release mode)
Not linking all libraries, but only the ones with a ....-d.lib ending (as supposed in another Stack Overflow thread)
I use Windows 7, Visual Studio Version 15.3.3
This is my code:
#include <SFML/Graphics.hpp>
#include <time.h>
#include <iostream>
int main() {
sf::RenderWindow window(sf::VideoMode(437, 437), "MattseChess!");
sf::Texture t1;
if (!t1.loadFromFile("C:/Users/Mattse/source/repos/Chess/Chess/images/figures.png")) {
std::cout << "Error loading texture" << std::endl;
}
return 0;
}
What shall I try out next?
You should always open files with a relative path ("images/figures.png"). It's relative from the executable.
And check with an other PNG images to see if it does not come from the image that SFML cannot load for any reasons (and try gimp to reexport it with different options like interlacing for example)
I'm guessing (from the C:\Users\ part) you are on a Windows system.
While Windows should support slashes as path separator, the official path separator in Windows is a backslash. It needs to be escaped in C++, so your full path would be:
"C:\\Users\\Mattse\\source\\repos\\Chess\\Chess\\images\\figures.png"
Problem fixed, it was in fact the case that I forgot to delete one library in the linker->input settings. I only have the ones with a -d ending now, even the ones which have NO -d equivalent got deleted.
List of linked libraries:
sfml-audio-d.lib
sfml-graphics-d.lib
sfml-main-d.lib
sfml-network-d.lib
sfml-network-s-d.lib
sfml-system-d.lib
sfml-system-s-d.lib
sfml-window-d.lib
sfml-window-s-d.lib
When I use string variables in Eclipse CDT (MinGW compiler) and I run the program, it doesn't show me anything. Here's my code:
#include <iostream>
using namespace std;
int main() {
string hw = "Hello, world!";
cout << hw << endl;
return 0;
}
So that doesn't show anything, but when I just do cout << "Hello, world!" << endl; it does work.
I also tried including <string>, <string.h>, "string" and "string.h" but still no success. The same code does work in VC++ and Codeblocks though.
I can reproduce this problem on my machine. The output does not appear. But it is not an output problem, but actually two problems before you get to main:
The program is failing to launch. If you try double-clicking on it in Windows Explorer, you will get an error message like this:
The program can't start because libgcc_s_dw2-1.dll is missing from
your computer. Try reinstalling the program to fix this problem.
Screenshot of above:
When launched from within Eclipse, this error message is silently swallowed, so how are you supposed to know!
Solutions/Workarounds
You need to get the environment correctly set up to launch the MinGW program because its DLLs are not installed on Windows PATH or other standard places DLLs are searched for.
Add C:\MinGW\bin to your PATH
Launch Eclipse from within a MinGW shell (has basically same effect as 1)
Run the program in debug mode, this causes the program to be launched as a child of GCC and that sets up
Other options (not tried by me) may include statically linking the offending library, see The program can't start because libgcc_s_dw2-1.dll is missing
File a CDT bug about the error message being hidden.
Extra info
If your program compiles, as I am sure it does based on your comments, changing the includes is probably irrelevant.
By adding an infinite loop around the couts I could immediately identify something more than simply an output not being shown was going on. Try the same thing on your machine, and also try running the program from within MinGW shell and from outside it.
So finally I’m not able to help myself out by researching anymore. Hopefully you can help me.
I recently decided to learn C++ in the context of my bachelor-thesis: My first aim is to read the pixel-values of a tiff-image with the libtiff-library. Yet, every call of a function of the library seems to break parts of my program.
Here’s the simple “HelloWorld”-Program, it works as it should:
#include "tiffio.h"
#include <iostream>
using namespace std;
int main() {
cout << "Hello" << endl;
// TIFF* tif = TIFFOpen("path to .tif", "r");
return 0;
}
When I uncomment the second line in main(), the code still does compile without errors (except the warning that ‘tif’ isn’t used) and I can start the program as usual. Yet nothing gets printed into the console anymore. Not “Hello” nor any errors.
Any suggestions where the error could be? The code should be alright, I guess I messed something up during the setup of the library or so. Here’s what I did:
I managed to set up eclipse (Mars, 32bit) for C++ and MinGW (32bit) on my 64bit Win7, then downloaded libtiff 4.0.4 and built it following this instruction.
I created a new C++-project with the mentioned code and did the following adjustments in the project-properties:
Project->Properties->C/C++ General->Paths and Symbols->Library
Paths-> Added “D:/… /tiff-4.0.4/libtiff/.libs”
Project->Properties->C/C++ Build->MinGW C++
Linker->Miscellaneous->Set Linkerflags to “-static-libgcc
-static-libstdc++”
Project->Properties->C/C++ Build->MinGW C++ Linker->Libraries-> Set
(-L) to “D:/… /tiff-4.0.4/libtiff/.libs” and (-l) to “libtiff”
I know the .tif is a valid file as I implemented parts of my program in C#, using the LibTiff.NET library by BitMiracle.
Thank you in advance!
Edit 1: The same error occures, even if TIFF* tif = TIFFOpen("path to .tif", "r"); is never called but written down in a dead part of the code. Debugging does not work either, the program seems to be terminated (exit value 0) before a single line is executed, without any error-reports.
I had the same issue and managed to get rid of it.
I set up eclipse (Mars) for C++ and MinGW on my 64bit Win7, then downloaded libtiff 4.0.4 and built it following this instruction.
After the build, I got two directories containing files:
include
tiff.h
tiffconf.h
tiffio.h
tiffio.hxx
tiffvers.h
lib
libtiff.a
libtiff.dll.a
libtiff.la
libtiffxx.a
libtiffxx.dll.a
libtiffxx.la
I also linked all include files and only the libtiff.a to my project and that solved it, ie, the other lines are now executed.
I hope, I helped with this post.
I am trying to move the code from a preliminary project to a new project (both made under Visual Studio 2012).
The original one has been made as a console application and I want the new to be a Windows application. I created an empty project and moved the files/set the library paths.
It is a simple OpenGL program with shaders.
EDIT:
It happens that even when I switch back to creating a Console application with the same .vcproj properties, I have a fatal error on Release and Debug.
You can find them below.
Why does my program crash? All the library paths are set just fine because it's the same settings used for a previous project with the same files that DID work (in a different solution).
Errors
Release crash location (outside a #ifdef _DEBUG in the dbghook.c
file)
int _debugger_hook_dummy;
__declspec(noinline)
void __cdecl _CRT_DEBUGGER_HOOK(int _Reserved)
{
/* assign 0 to _debugger_hook_dummy so that the function is not folded in retail */
(_Reserved);
_debugger_hook_dummy = 0;
}
Debug crash location (fread.c) - a pop-up error window appears
(Debug assertion failed):
_VALIDATE_RETURN((stream != NULL), EINVAL, 0);
After cutting my source file in parts, I managed to debug this. The problem was not the port (sorry).
I had minor issues dealing with the location of the executable: Visual Studio puts them by default in SolutionDir/DebugorRelease while I was looking for them in ProjectDir/DebugorRelease.
But the main problem came from a change of function.
There is a side file I use to load textures, which is pretty old and uses fopen to open files.
Following the warnings I got, I changed all the fopen occurrences to fopen_s, with all necessary modifications. That's the precise line where the program crashed.
I put back the fopen version, checked the file locations, and it went back to executing (not in Visual Studio but through command line only, like the original project). That's for the Console Application.
To make it a Windows Application, the following line does the job, and this time, though command-line-only, it works for real.
#pragma comment( linker, "/subsystem:\"windows\" /entry:\"mainCRTStartup\"" )
Yesterday I decided to download, install, and attempt to use Allegro 5. I also downloaded Code::Blocks 12.11 w/ the MinGW compiler. I set up everything and installed everything correctly (or so I thought) and tried to run a sample code to see if it would work:
#include <stdio.h>
#include <allegro5/allegro.h>
int main(int argc, char **argv){
ALLEGRO_DISPLAY *display = NULL;
if(!al_init()) {
fprintf(stderr, "failed to initialize allegro!\n");
return -1;
}
display = al_create_display(640, 480);
if(!display) {
fprintf(stderr, "failed to create display!\n");
return -1;
}
al_clear_to_color(al_map_rgb(0,0,0));
al_flip_display();
al_rest(10.0);
al_destroy_display(display);
return 0;
}
When I attempt to compile and run the program an error message box appears saying "The procedure entry point _gxx_personality_v0 could not be located in the dynamic link library libstdc++-6.dll." I searched the web for about an hour trying to find a fix for this problem, like I do for most things, but I came up empty handed. I'm wondering if anyone has any ideas for any fixes to this problem, if so, let me know ASAP! Thanks in advance!
__gxx_personality_v0 is used in the exception handling of the C++ library. MinGW can support a couple different exception models on the x86: sjlj (setjmp/longjmp) or DWARF (DW2). As far as I know, which model will be used is compiled into the compiler - it's not something that can be selected with a command line option.
The sjlj exception model will link to __gxx_personality_sj0, the DW2 exception model links to __gxx_personality_v0. It seems like your compiler is building for the dw2 exception model, but at runtime it's finding a libstdc++-6.dll that was built with the sjlj model. See if you have multiple versions of libstdc++-6.dll on youR system, and see if copying another one to the same directory as your program fixes the problem.
You can use nm libstdc++-6.dll | grep personality to see which exception 'personality' the DLL is using.
I ran into this as well. Did some searching, someone mentioned paying attention to whether or not you were in Debug or Release Mode. This applies to Code::Blocks specifically. I found I was in Debug Mode. I changed that to Release Mode and my program compiled and ran.
I am troubled by this though... It seems to me it should work in both modes, so how do I fix it so that it will? I have no answer there. Maybe someone will comment with the solution. In the meantime, compile and run in Release Mode instead of Debug Mode.
I just did a little mad science, removed the libstdc++6.dll from MinGW/bin and put it in another folder. Then I copied over the same file from Gimp/bin. No more linker error, instead I get an error that says the application failed to start :( Still compiles and runs in Release Mode though.