I have followed (twice, now) the setup guide for getting SFML up and running in Visual Studio. I have made sure that the proper .lib files and directories are being pointed to in the project's settings and that the required .dll's are present in the application's working directory, as per the guide.
I am trying to run the following: (ambitious, I know...)
#include "stdio.h";
#include <iostream>;
#include <SFML/Graphics.hpp>;
int main ()
{
sf::RenderWindow window( sf::VideoMode( 640, 480 ), "Title" );
std::cin.get();
}
Compile is successful, but as soon as the application starts, I get:
Exception thrown at 0x56D5EEB6 (sfml-system-d-2.dll) in D20 RPG.exe: 0xC0000005: Access violation reading location 0xCCCCCCD8.
With the first line commented, the application starts and finishes without a problem.
Do I need to locate the SFML source and compile it myself? It is a fairly sprawling library with a lot of dependencies, so that's something I've been avoiding unless someone thinks it might help. My experience with C++ and VS is shallow enough that I think I'd be more likely to introduce more problems before solving this one.
I was able to get this code working by creating a new empty console application project and using the NuGet package manager interface to install the sfml-graphics, sfml-window, and sfml-system packages.
Related
I have recently started working on a small program with SDL2 and c++. In this program I used IMG_LoadTexture() to load a texture however it just would not want to work, the program could not find the image. So I chanced my program to use SDL_loadBMP(), did not work. After hours of endlessly looking for bugs I still could not find anything.
When I started my project I saved it to my D: disk and not on my C: disk. So when I was about to give up on the whole project I copied my exe, image and libraries to my C: disk and Boom it worked.
So I have no idea why this happens. I refer to my image with a relative path but it just doesn't want to work on my D: disk. Is this a bug? or might it have something to do with settings related to my disk? And how can I make it work on my D: disk?
P.S. I am using windows 7
P.S.S. My apologies in advance for any horrible grammar and spelling mistakes.
Is the working directory of you executable the same you assume it is? On windows happened more than one time that working directory was not the path I believed. With certain compiler configurations the working directory is not the same on wich the executable is, you have to change working directory looking at documentation of your IDE.
What frequently happened to me
CURRENT WORKING DIR
D:/projectdir/
EXPECTED WORKING DIR
D:/projectdir/bin/debug/
where files really are:
D:/projectdir/bin/debug/app.exe
D:/projectdir/bin/debug/texture.png
which files app is trying to loading when launched from IDE:
D:/projectdir/app.exe
D:/projectdir/texture.png
You can quickly test wich is current working directory by calling equivalent on windows of
getcwd (answer from here )
#include <WinBase.h>
int main() {
TCHAR pwd[MAX_PATH];
GetCurrentDirectory(MAX_PATH,pwd);
MessageBox(NULL,pwd,pwd,0);
}
I recently started working with WxWidgets (2.9.4) and was working through a tutorial I found, but it seems that I'm unable to load any images. I've already properly used the handler (for PNG) and the problem happens at run-time. Below is an image of the popup that is displayed when attempting to run the program.
Here is the code:
wxPNGHandler *handler = new wxPNGHandler;
wxImage::AddHandler(handler);
wxBitmap exit;
exit.LoadFile(wxT("exit.png"), wxBITMAP_TYPE_PNG);
wxToolBar *toolbar = CreateToolBar();
toolbar->AddTool(wxID_EXIT, exit, wxT("Exit"));
toolbar->Realize();
Connect(wxID_EXIT, wxEVT_COMMAND_TOOL_CLICKED, wxCommandEventHandler(mainWindow::exitProg));
Any help is appreciated.
EDIT: I forgot to mention that when I click Cancel, this happens:
I placed the exit.png file in the build directory (/Debug or /Release) as well as the source code directory, but it still has yet to see it.
What is your working directory?
If you are using visual studio and running using the interface ( F5 or ctrl-F5 or the little run button in the toolbar ) then your working directory is the folder containing the project file. So try copying your image file there.
Or open a command window, cd to one of your build directories, and run your app from the command line.
In general, to avoid this sort of problem, I alter the project properties so that the executable is NOT stored in one of the build folders, but in a new folder ( which I usually call 'bin' - my unix roots are showing! ) and also alter the debugging properties so that the working directory is the bin folder.
There are a couple of advantages to this technique:
Both the release and trhe debug version use the same folder, so you only need one copy of any extra file, like your image file.
It is easy to see the executable and extra files in the working directory without being distracted by all the .obj files that end up in the build folders
IMHO this is well worth the little extra trouble in maintaining non default project properties.
First of all, to avoid problems deep inside wxToolBar, always check the return code of LoadFile() or, alternatively, use wxBitmap::IsOk() to check that the bitmap was successfully loaded.
Second, while adding the handler explicitly as you did is perfectly fine, I'd recommend to just call wxInitAllImageHandlers() as it's simpler and has no real drawbacks unless you are looking to create the smallest program possible.
Finally, to address your real problem, the file clearly doesn't exist at the path you're loading it from. You can, of course, solve this by being careful not to change your working directly (or restore it after changing it) in your program and by placing the file in the correct place. But this is, as you discovered, error-prone, so a better idea is to always use full paths to your resources. To construct them, you will find wxStandardPaths useful, in particular its GetResourcesDir() method.
I installed the Assimp library on windows, and liked the files then just copy-pasted the SimpleOpenGL sample and deleted the struct words(most of them) In order to clear the errors I was getting.
Now, I do not have any errors but the program tells me this whenever I try to run it:
The application was unable to start correctly (0xc0150002).Click OK to close the application.
Any ideeas for a fix for this ( I have all the dlls from assimp in the project folder. )
Just use renamed Assimp32.dll to Assimp32d.dll
I'm learning SFML library and i picked a code from the tutorial. it opens a window and it should make me able to close it again but when i close it it says
Debug Error!
Run-Time Check Failure #2 - stack around variable 'App' was corrupted.
and then the console stops working.
this is my code:
int main()
{
// Create the main window
sf::Window App(sf::VideoMode(800, 600, 32), "SFML Events");
while (App.IsOpened())
{
// Process events
sf::Event Event;
while (App.GetEvent(Event))
{
// Close window : exit
if (Event.Type == sf::Event::Closed)
App.Close();
// Escape key : exit
if ((Event.Type == sf::Event::KeyPressed) && (Event.Key.Code == sf::Key::Escape))
App.Close();
}
// Display window on screen
App.Display();
}
return EXIT_SUCCESS;// = return 0
}
linking to the debug libraries are
sfml-system.lib
sfml-window.lib
sfml-system-d.lib//these are debug files
sfml-window-d.lib
if i ramove the first 2 and built my program it doesn't give errors but when i open it it says :
the application was unable to start correctly (0xc0150002). click ok to close the application
i have a 64 bit computer. and in microsoft vc++ 2010 i can do build solution or debug and i always do build solution.
and i am building in release mode but i have also tried both and they both didn't work
could someone please tell me what i could do to prevent this from happening or how this comes.
For these application startup issues,it is always a good idea to check if all dlls in the dependency closure are accessible - that is, are they all in the search PATH? We usually use dependency walker to check which dlls are missing, or use gflags for runtime diagnostic
While put your dlls with your exe in same folder works, it does not scale well, one way I usually do is put the library path in PATH environment variable.
And one thing to notice, sfml comes with prebuilt binrary for vs2005 and vs2008, as you are using vs2010, the underlying c runtime library(msvcrt) is different, there would be potential problems - you would better build sfml from source yourself using vs2010 or use vs2005/vs2008, just to be consistent
if you wouldnt like to use DLLs and would like to compile SFML into exe, here is tutorial:
2.0 http://www.sfml-dev.org/tutorials/2.0/start-vc.php
you need to add preprcessor directive SFML_STATIC , and include additional libs u are using in your program into linker -> input
I also had some related problems when I first time used this (and equivalent libs). Here is some points to take in count:
Do not use precompiled libraries/dlls. Learn how to use CMake, boost_build (boost libraries), Scons (mongoDB) etc. and build libraries according to currently used compiler/platform (of course if there is such possibility). After some time this process became pretty easy and simple and this will save a lot of time later for other projects.
Read SFML tutorials on making a simple project. They are easy to read and understand. May try to generate also examples with CMake and build them to see how they work. Another good tutorial is the book on SFML programming (which have a huge push on using C++11, which I think is great).
As pointed out add SFML_STATIC to "Preprocessor definitions" if don't want to use DLLs and I think is better to set "Windows (/SUBSYSTEM:WINDOWS)" in linker options (if I correctly understood from "and then the console stops working" statement).
Better to place libsndfile-1.dll and openal32.dll in release/debug folder where app is generated, from what I saw VC++ have a bad behavior on finding dlls from provided paths.
#include <FL/Fl.H>
#include <FL/Fl_Window.H>
int main() {
Fl_Window win(400, 400);
win.show();
return Fl::run();
}
I'm compiling with "fltk-config --compile main.cpp". The code compiles without incident, but when the application is run I only get a console window and no GUI.
I've also tried using fluid from terminal (via "fluid main.cpp"); I'm not even sure I'm using this correctly since, as I understand, fluid is a graphical editor. In any case, the result is "Can't open display: ". I found the same error but for a different situation here. Somebody in that thread suggested doing "export DISPLAY=:0.0", which I tried. Now when using fluid the error has simply changed to "Can't open display: :0.0".
It's worth noting that I've also tried using Qt4 as a framework (using qmake/make to compile), but I have the exact same problem. Console loads, no GUI of any sort, despite using code that various sources say should work.
edit
I found this question. I used DependencyWalker to find .dlls used by my .exe, and placed copies of those .dlls directly into my project folder. This did not fix my problem, or change it in any way. For reference, the .dlls I used were: cygfontconfig-1, cyggcc_s-1, cygstdc++-6, cygwin1, cygX11-6, cygXft-2, kernel32.
I also tried the same solution for Qt, again with no success. In that case, the .dlls were cygwin1, cyggcc_s-1, cygstdc++-6, cygqtcore-4, cygqtgui-4, kernel32.
For some good news, I've found that can successfully build an application with the Qt Creater SDK, so the problem lies somewhere with my manual compiles only. In any event, I'd still like to solve this problem. I dislike using an SDK for small projects, and I'd like to keep my library options open.
If fltk-config --cxxflags and fltk-config --ldflags do not output -mno-cygwin, then your FLTK was compiled to work with Cygwin's X Window System - something you probably want to avoid. Add -mno-cygwin to your Makefile and your FLTK application should work.
I always liked MinGW+MSYS more.