Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: sf::RenderWindow::Clear() causing Unhandled exception  (Read 17660 times)

0 Members and 1 Guest are viewing this topic.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
sf::RenderWindow::Clear() causing Unhandled exception
« Reply #15 on: April 29, 2010, 02:58:29 pm »
Several users have a problem with sf::RenderTarget::Clear. However it can only be a driver or OpenGL problem, all this function does is to call glClearColor and glClear. It can't crash.
Laurent Gomila - SFML developer

nulloid

  • Full Member
  • ***
  • Posts: 134
    • View Profile
sf::RenderWindow::Clear() causing Unhandled exception
« Reply #16 on: April 29, 2010, 04:54:39 pm »
Workaround: check your view's dimensions (width, height, position), and draw a rectangle... nothing better came into my mind :)

fazeli

  • Newbie
  • *
  • Posts: 9
    • View Profile
sf::RenderWindow::Clear() causing Unhandled exception
« Reply #17 on: April 30, 2010, 06:52:57 pm »
Thanks for the info Laurent and the help and suggestions nulloid.  Just one further question Laurent, is it normal for those experiencing the problem to have it work out when using the -d.libs?

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
sf::RenderWindow::Clear() causing Unhandled exception
« Reply #18 on: April 30, 2010, 07:57:58 pm »
Quote
Just one further question Laurent, is it normal for those experiencing the problem to have it work out when using the -d.libs?

No, unless they compile in debug mode.
Laurent Gomila - SFML developer

WSPSNIPER

  • Newbie
  • *
  • Posts: 28
    • View Profile
im having the same problem!
« Reply #19 on: May 09, 2010, 05:55:34 am »
did you find a fix yet?

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
sf::RenderWindow::Clear() causing Unhandled exception
« Reply #20 on: May 09, 2010, 11:40:19 am »
I can't find a fix if I don't find the problem first ;)
Laurent Gomila - SFML developer

Amablue

  • Newbie
  • *
  • Posts: 13
    • View Profile
sf::RenderWindow::Clear() causing Unhandled exception
« Reply #21 on: May 17, 2010, 09:58:07 am »
I'm running with the 1.5 packages installed from synaptic on ubuntu and I'm getting the crash too. I'm not linking against the debug libraries, just the regular ol static libraries.

When I call window.Clear() I get a seg fault. When I call glClearColor(...) followed by glClear(GL_COLOR_BUFFER_BIT) it runs just fine. Until someone figures out why window.Clear() is dying on me I'll jsut use glClear as a workaround.

 :?

Edit:

I played around a little bit and have no idea what the problem is. I looked at the source and I can't see anything that could be going wrong. I tried remaking the exact code that Clear calls, but when I do that it runs fine.

Code: [Select]
bool Activate(sf::RenderWindow& App, bool Active)
{
    if (Active)
        return App.SetActive();
    else
        return false;
}

void Clear(sf::RenderWindow& App, const sf::Color& FillColor)
{
    if (Activate(App, true))
    {
        glClearColor(FillColor.r / 255.f, FillColor.g / 255.f, FillColor.b / 255.f, FillColor.a / 255.f);
        glClear(GL_COLOR_BUFFER_BIT);
        Activate(App, false);
    }
}

int main()
{
    // Create the main rendering window
    sf::RenderWindow App(sf::VideoMode(800, 600, 32), "SFML Graphics");
   
    // Start game loop
    while (App.IsOpened())
    {
        // Process events
        sf::Event Event;
        while (App.GetEvent(Event))
        {
            // Close window : exit
            if (Event.Type == sf::Event::Closed)
                App.Close();
        }

        // Clear the screen (fill it with black color)
        //App.Clear(sf::Color(0, 0, 0));
       
        // Uncommenting the line above crashes, yet the one below works fine.
        Clear(App, sf::Color(0, 0, 0));

        // Display window contents on screen
        App.Display();
    }


Baffling. I did notice that SFML_DEBUG was defined, even though I'm not linking against the debug libraries as far as I know.

Code: [Select]

game : *.cpp *.h
g++ -o game \
main.cpp Border.cpp Game.cpp Widget.cpp \
-I/usr/local/include/luajit-2.0 -lluajit-5.1 \
-lsfml-graphics -lsfml-window -lsfml-system -Wall -Weffc++ -Wextra \
-Wshadow -Wformat-nonliteral -Wformat-security -Winit-self -Wundef

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
sf::RenderWindow::Clear() causing Unhandled exception
« Reply #22 on: May 17, 2010, 11:36:08 am »
Thanks a lot for your help :)

Quote
I did notice that SFML_DEBUG was defined, even though I'm not linking against the debug libraries as far as I know.

How did you notice that SFML_DEBUG is defined?

Can you try adding -DNDEBUG to your command line and see if the crash is still there?
Laurent Gomila - SFML developer

Amablue

  • Newbie
  • *
  • Posts: 13
    • View Profile
sf::RenderWindow::Clear() causing Unhandled exception
« Reply #23 on: May 17, 2010, 05:21:32 pm »
While I was reimplementing the Clear method I noticed GLCheck was a macro that only does anything if SFML_DEBUG is defined. I omitted it in the code snipped I posted below though. When nothing I did crashed, I though "maybe the code the GLCheck calls is what's crashing" but GLCheck only did anything if SFML_DEBUG was defined, so I just threw in a quick check to see if it was:

Code: [Select]

#ifdef SFML_DEBUG
    std::cout << "Test!" << std::endl;
#endif


When I started running my program I was spammed with "Test!" After seeing that it was actually defined I tried copying and pasting the full contents of the GLCheck macro and wrapping the glClear and glClearColor calls in it, but that still didn't crash it.

Edit: Adding -DNDEBUG didn't have any effect. I'm going to try compiling the source and using those libraries when I get home from work today and see if that gives me better luck than the packages from synaptic. I'll let you know what happens.

Amablue

  • Newbie
  • *
  • Posts: 13
    • View Profile
sf::RenderWindow::Clear() causing Unhandled exception
« Reply #24 on: May 18, 2010, 06:44:50 am »
So I removed the packages I was using from synaptic, and instead downloaded the trunk and built it from there, and now it seems to work. In order to get it to compile though I had to get a few extra libs that I didn't seem to have before. If I didn't have those libs, I don't see how the 1.5 packages could have run properly either (and they didn't include them as dependencies) so I wonder if that's the problem.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
sf::RenderWindow::Clear() causing Unhandled exception
« Reply #25 on: May 18, 2010, 08:35:01 am »
Hmm, weird. Which packages was it?
Laurent Gomila - SFML developer

Amablue

  • Newbie
  • *
  • Posts: 13
    • View Profile
sf::RenderWindow::Clear() causing Unhandled exception
« Reply #26 on: May 19, 2010, 07:39:34 am »
I now have to link against GL, and I needed to install and link against glfw in my project. My makefile went from what you see in on of my previous posts to the following:

Code: [Select]
game : *.cpp *.h
g++ -o game \
main.cpp Border.cpp Game.cpp Widget.cpp \
-I/usr/local/include/luajit-2.0 -lluajit-5.1 \
-L/home/alex/src/cpp/sfml/lib/ -isystem/home/alex/src/cpp/sfml/include/ \
-lGL -lglfw \
-lsfml-graphics-s -lsfml-window-s -lsfml-system-s -Wall -Weffc++ -Wextra \
-Wshadow -Wformat-nonliteral -Wformat-security -Winit-self -Wundef


(I have -isystem instead of -I because otherwise I get a bunch of compiler warnings about things like destructors in sfml not being marked virtual and stuff)

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
sf::RenderWindow::Clear() causing Unhandled exception
« Reply #27 on: May 19, 2010, 08:49:28 am »
Quote
I now have to link against GL

Because you have OpenGL code in your application ;)

Quote
and I needed to install and link against glfw in my project

This one is definitely not necessary. I guess it links itself to the actual library that you need, so it works. What errors do you get without glfw?
Laurent Gomila - SFML developer

Amablue

  • Newbie
  • *
  • Posts: 13
    • View Profile
sf::RenderWindow::Clear() causing Unhandled exception
« Reply #28 on: May 19, 2010, 05:38:06 pm »
Quote from: "Laurent"
Because you have OpenGL code in your application ;)


Nope :)

The only openGL code I had was the call to glClearColor and glClear, both of which have been removed. It complains about gl calls in sfml

http://pastebin.com/Ub0BQU4c

Quote from: "Laurent"
This one is definitely not necessary. I guess it links itself to the actual library that you need, so it works. What errors do you get without glfw?

If I include GL, then I just get these:

http://pastebin.com/24fDLs6M

to compile this, I'm just just the sample program from the tutorial:

Code: [Select]
#include <SFML/Window.hpp>
#include <SFML/Graphics.hpp>
int main()
{
    sf::RenderWindow App(sf::VideoMode(800, 600, 32), "SFML Graphics");
    while (App.IsOpened())
    {
        sf::Event Event;
        while (App.GetEvent(Event))
        {
            if (Event.Type == sf::Event::Closed)
                App.Close();
        }
        App.Clear();
        App.Display();
    }
}

scross

  • Newbie
  • *
  • Posts: 14
    • View Profile
sf::RenderWindow::Clear() causing Unhandled exception
« Reply #29 on: June 08, 2010, 10:54:11 pm »
I'm using Linux Mint, which is basically the same as Ubuntu and I encountered this same problem, with all my SFML-based programs working fine until I recompiled them. It turns out the earlier version (1.5) had installed its libraries to /usr/lib, whereas version 1.6 had installed its libraries to /usr/local/lib. I assumed this meant that my app was being linked to the old libs (perhaps meaning the wrong dynamic libs are used), and the problem somehow stemmed from that. Anyway, switching to root and eliminating the version 1.5 libraries has solved the problem.

 

anything