SFML community forums

Help => Graphics => Topic started by: Gigotdarnaud on April 03, 2014, 12:24:25 pm

Title: [SOLVED] sf::RenderTexture crash with latest SFML version (MSVC12)
Post by: Gigotdarnaud on April 03, 2014, 12:24:25 pm
Hello,

I am experimenting an odd issue with this code:
#include <SFML/Graphics.hpp>

int main()
{

    sf::RenderTexture test;
    test.create(150, 150);

    sf::RectangleShape bg(sf::Vector2f(50, 50));
    bg.setFillColor(sf::Color(255, 0, 0));

    test.draw(bg);

    return 0;
}

The call to sf::RenderTexture::draw crashes the program.

I did not have this issue back when I used MSVC10 and the SFML 2.1 binaries downloaded from the site. Since I needed advanced C++11 features, I upgraded to MSVC12, built SFML from source using SFML Installer (http://en.sfml-dev.org/forums/index.php?topic=13722.0). Everything compiled as usual (it links just fine, the binaries were indeed made by and for MSVC12), until I started to call sf::RenderTexture to, well, render on a texture.

Note that sf::RenderWindow works just fine.

I am rebuilding SFML one more time right now, just in case something went wrong the first time, but it seems unlikely.

Any idea?


EDIT:
Even with the rebuild it crashes. I believe we can rule that one out.
Title: Re: sf::RenderTexture crash with latest SFML version (MSVC12)
Post by: eXpl0it3r on April 03, 2014, 12:51:05 pm
You should call clear() and display(), but I guess that's not the issue. Instead it's probably some context problem.

Please provide the full error message and the call stack when the application crashes.
Title: Re: [SOLVED] sf::RenderTexture crash with latest SFML version (MSVC12)
Post by: Gigotdarnaud on April 03, 2014, 03:10:10 pm
Problem solved!
As it turns out, the project had been using the wrong DLLs all along.

When building a new project in Visual Studio (I usually don't use it), the runtime couldn't find the DLLs, and when copied near the executable the code didn't crash anymore.
I returned to my usual development environment, did the same thing and voilĂ .
Out of curiosity, how come the call to the DLLs didn't crash closer to the app entry point? Aren't dynamic libraries version-ed or something?