[SOLVED] SFML 2. Stop drawing on window

[lzedl]

Hello there

I have a strange problem with drawing sprites on screen.
Here is an example:

main.cpp

#include <SFML/Graphics.hpp>
#include <SFML/System.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(800, 600, 32), "SFML works!");
    sf::Text text("Hello SFML\nand here am i");
    sf::Font font;
    font.loadFromFile("XPDR06.TTF");
    text.setFont(font);
    text.setCharacterSize(8);
    sf::Texture texture;
    texture.loadFromFile("sprite.png");
    sf::Sprite sprite(texture);
    sf::Clock clock;
    while (window.isOpen())
    {
        if(clock.getElapsedTime().asMilliseconds() > 1000/30)
        {
            sf::Event event;
            while (window.pollEvent(event))
            {
                if (event.type == sf::Event::Closed)
                    window.close();
            }
            window.clear();
            window.draw(text);
            sprite.move(1,0);
            window.draw(sprite);
            window.display();
            clock.restart();
        }
    }

    return 0;
}
 

It works fine, but if i delete "window.draw(text);" it freeze drawing on about second frame.
What i do wrong?
I spend a lot of time to find the place, that affect on process...

Is it bug? or it's my mistake?
Thanks anyway =)

PS: Sorry for bad English

[eXpl0it3r]

Define "it freeze drawing on about second frame" further...
Does the sprite stop moving? (If so this shouldn't happen)
Obviously if you remove the draw call the text won't get drawn anymore = it will not show up.

Additionally don't do this:

if(clock.getElapsedTime().asMilliseconds() > 1000/30)

Instead just insert after the window creation this:

window.setFramerateLimit(30);

The reason is that your method creates a busy-waiting-loop (google it for more information) and thus using all the CPU power it can get, whereas setFramerateLimit always puts the application to sleep and thus freeing CPU time.

[lzedl]

Define "it freeze drawing on about second frame" further...
Does the sprite stop moving? (If so this shouldn't happen)
Obviously if you remove the draw call the text won't get drawn anymore = it will not show up.

If i compile code with "window.draw(text);" everithing is OK.
But if remove it sprite stop moving - yes =) but loop still continues...
I don't need text drawing, but i found that it affects on all window drawing

Additionally don't do this:

if(clock.getElapsedTime().asMilliseconds() > 1000/30)

Instead just insert after the window creation this:

window.setFramerateLimit(30);

The reason is that your method creates a busy-waiting-loop (google it for more information) and thus using all the CPU power it can get, whereas setFramerateLimit always puts the application to sleep and thus freeing CPU time.

Thanks =) I keep it in mind)

[eXpl0it3r]

It should not and does not on my system, so it's not SFML fault, but something wrong on your end, but I've no idea what.

Btw it's a good practice to keep the updating part (moving sprites around, handeling inputs & events, etc.) seperated from the drawing part. So your sprite.move(1, 0); should come infront of the drawing statements.

[lzedl]

It should not and does not on my system, so it's not SFML fault, but something wrong on your end, but I've no idea what.

It makes me sad =( but thanks anyway)

Btw it's a good practice to keep the updating part (moving sprites around, handeling inputs & events, etc.) seperated from the drawing part. So your sprite.move(1, 0); should come infront of the drawing statements.

Thanks =) But it just an example) I making a game and want to port it from SDL to SFML, because i found it very cool, fast and simple (Captain Obvious), but i faced with this problem =(

[eXpl0it3r]

I guess the examples that come with the SFML SDK work fine right?
Also is your graphics driver uptodate?

[lzedl]

I guess the examples that come with the SFML SDK work fine right?
Also is your graphics driver uptodate?

Right! Spend some hours with drivers settings i switch my noveau driver to proprietary nvidia driver and all works fine =)
Thanks for advice =)

[lzedl]

I discovered that the problem wasn't exactly in driver, but in nouveau-dri package (ArchLinux) that represents hardware-accelerated 3D support. If you on linux and nvidia video card - keep it in mind.