Messages

1

General discussions / Re: SFML 2.3 released!

« on: June 09, 2015, 01:08:32 am »

This sounds great! Will try out the new features when I get the chance.
Great to hear you can get a core context now, I'll have to test it later to see if it works with 4.x as well.

2

Window / Re: Error taking screenshot in the first frame

« on: January 20, 2015, 03:11:55 pm »

Thanks for the replies it does make sense, although I had the same thought, does that mean it's a frame behind? It's no big deal for my purposes though.

Edit: As a side note, I'm happy to see that the SFML method of taking a screenshot still seems to work just fine when the screen is bigger than my actual monitor (Just took a 3000x2000 screen and it seems to draw everything correctly)

3

Window / Error taking screenshot in the first frame

« on: January 20, 2015, 02:24:35 pm »

Could someone kindly tell me why this doesn't work, and if it is considered a bug or not?

The following code does not correctly take a screenshot, the PNG file rendered is blank with RGBA (0, 0, 0, 0).
I have the following code:

#include <SFML/Graphics.hpp>
const int ScreenWidth  = 3000/4;
const int ScreenHeight = 2000/4;

int main()
{
    sf::RenderWindow window(sf::VideoMode(ScreenWidth, ScreenHeight), "SFML Animation"/*, sf::Style::None*/);

    sf::RectangleShape rect(sf::Vector2f(100, 100));
    rect.setPosition(sf::Vector2f(100, 100));

    while(window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
        }

        window.clear(sf::Color::Blue);
        window.draw(rect);
        window.display();

        //static int i = 0;
        //if (i++ > 10)
        //{
            sf::Image screenshot = window.capture();
            screenshot.saveToFile("test_big000.png");
            return 0;
        //}

    }
}

If I uncomment the last lines to be the following, to allow more frames to be processed before a screenshot, a correct screenshot is  made:

        static int i = 0;
        if (i++ > 10)  // just to make it have to process the loop a few times
        {
            sf::Image screenshot = window.capture();
            screenshot.saveToFile("test_big000.png");
            return 0;
        }
 

Short version:
Why does the capture() function not work on the first frame of the program?
Is this intended behavior? Couldn't find anything with search to verify this claim.

Also note that the screenshot.saveToFile() is returning true.
I'm on Windows 7, if that matters, using SFML 2.2 compiled from github about a week ago.

4

General / Re: Code compiling fails with cmake

« on: November 02, 2014, 07:53:51 pm »

Sorry I thought I was on topic and that my issue was similar enough not to make a new thread.
My error messages were very similar to the topic's.

That's correct I have no idea what I am doing. I was trying to follow the site's tutorial on how to compile SFML (I thought that was what ZamenWolk was trying to do as well), and I ran into these problems when trying to statically link things.

I thought that the tutorial provided by the site would be all I need to do this basic thing, but I am wrong? Thanks for the replies. I guess this is off topic so I'll stop.

5

General / Re: Code compiling fails with cmake

« on: November 02, 2014, 06:29:03 pm »

Okay and just to make sure, this is within the file

Code: [Select]

SFML-master/cmake/Modules/FindSFML.cmake?[/s]

Edit: Wait no it's not in FindSFML.cmake, it's just a comment in that file.
I don't know what file I'm supposed to edit to link statically correctly...


My apologies if this is written in the tutorial but I can't find it.

6

General / Re: Code compiling fails with cmake

« on: November 02, 2014, 05:54:59 am »

Hi Laurent, I got similar errors. I'm new to cmake (I was able to follow this site's tutorial on building SFML but nothing besides that) but I must've missed the bit about linking SFML dependencies so that there aren't undefined OpenGL references.

Could you explain where exactly I should put that ${SFML_DEPENDENCIES} line?  Is it an option on the Cmake GUI or do I have to manually edit a cmake file?

7

Graphics / Re: SFML OpenGL version

« on: September 15, 2014, 02:22:06 am »

Thanks for the reply, I should be able to get some nvidia stuff to work after I mess around with some with windows and linux... ugh why can't the hardest part about programming just be programming. 

8

Graphics / SFML OpenGL version

« on: September 14, 2014, 09:06:11 pm »

Sorry if this doesn't belong here or has been discussed. I have tried to search for opengl and the only useful thing I've found is this little snippet http://en.sfml-dev.org/forums/index.php?topic=1817

What version of OpenGL does SFML use? Apparently Intel drivers don't support 3.3+ so does SFML use OpenGL 2.1? In your opinion, is it okay to still learn OpenGL through version 2.1 even though it's old? Thanks for reading


Edit: Found this http://en.sfml-dev.org/forums/index.php?topic=1034 so would that mean that SFML uses 1.1? or does that just mean there's a bunch of pre-processor macros to keep cross-compatibility with older OpenGL versions?

Edit 2: The search function on the forum seems to not be able to find all instances of "opengl". For instance, I can't seem to find this page http://en.sfml-dev.org/forums/index.php?topic=16281.0 when searching for opengl

9

SFML website / Re: We have Moved!

« on: August 20, 2014, 10:51:42 pm »

Nice to read this, things do seem to be faster!

10

Graphics / Re: Limiting framerate with mouse-window interactions causing lag

« on: July 21, 2014, 05:02:57 pm »

Input lag, as in, when moving the cursor around while letting it be visible, the "custom cursor" significantly trails behind the actual cursor. I first noticed this when implementing a drag-and-drop feature to one of the programs I was working on, having vsync turn on in the code would make it very annoying for the user.

I'm not just talking about inherent input lag from having a sprite follow the cursor to begin with, if I don't set a cap on the CPU and let my processor go all out, there isn't a noticeable problem.

This can also be seen if I make vsync be on in https://github.com/SFML/SFML/wiki/Tutorial:-Using-View

Does anyone else besides me get the input lag when the vsync line is not commented in the first example code? Setting the framerate limit makes the lag significantly lower, but it's still there and either way doesn't solve the original problem. Or do most of you guys just let even simple applications take up so much processor energy, heating up your computer unnecessarily... I just don't understand.

11

Graphics / Re: Limiting framerate with mouse-window interactions causing lag

« on: July 21, 2014, 02:01:07 am »

Like this?

(click to show/hide)

int main()
{
    sf::RenderWindow window(sf::VideoMode(800, 600), "Hidden Cursor");
    //window.setMouseCursorVisible(false); // Hide cursor
    window.setVerticalSyncEnabled(true);
    //window.setFramerateLimit(60);

    sf::View fixed = window.getView(); // Create a fixed view

    // Load image and create sprite
    sf::Texture texture;
    texture.loadFromFile("cursor.png");
    sf::Sprite sprite(texture);

    sf::Vector2f mMousePos(0.f, 0.f);

    while(window.isOpen())
    {
        sf::Event event;
        while(window.pollEvent(event))
        {
            if(event.type == sf::Event::Closed)
            {
                window.close();
            }
            else if (event.type == sf::Event::MouseMoved)
            {
                mMousePos.x = event.mouseMove.x;
                mMousePos.y = event.mouseMove.y;
            }
        }

        sprite.setPosition(mMousePos);

        window.clear();
        window.setView(fixed);
        window.draw(sprite);
        window.display();
    }

    return EXIT_SUCCESS;
}

It's virtually the same lag, can't tell a difference, but thanks for the reply.
Edit: It's also not a problem with debug, the performance gain/decreased lag in release optimizations for this is barely noticeable as well.

12

Graphics / Limiting framerate with mouse-window interactions causing lag

« on: July 21, 2014, 12:59:30 am »

I was trying to make an efficient way to drag-and-drop sprites or other objects. I got it to work, but when doing this, I noticed that when my code limited the framerate of the program in order to save processor usage (whether I'm using a fixed timestep or not), it caused updates that relied on mouse click/move and window interaction to lag.

The following code is a slight modification to one of the site's tutorials (https://github.com/SFML/SFML/wiki/Tutorial:-Change-Cursor ) that I used as a minimal way to show the problem I'm having:

I have the framerate-limiting code at the beginning commented out, if you uncomment either the FramerateLimit line or the V-sync line (the latter especially, not at same time, I know), it causes lag. Please, what can I do to prevent this?

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(800, 600), "Hidden Cursor");

    ///***Uncommented so that you can see the "lag".***
    //window.setMouseCursorVisible(false); // Hide cursor

    //***UNCOMMENT ONE OF THESE***
    //window.setVerticalSyncEnabled(true);
    //window.setFramerateLimit(60);

    sf::View fixed = window.getView(); // Create a fixed view

    // Load image and create sprite
    sf::Texture texture;
    texture.loadFromFile("cursor.png");
    sf::Sprite sprite(texture);

    while(window.isOpen())
    {
        sf::Event event;
        while(window.pollEvent(event))
        {
            if(event.type == sf::Event::Closed)
            {
                window.close();
            }
        }

        // Set position
        sprite.setPosition(static_cast<sf::Vector2f>(sf::Mouse::getPosition(window)));

        window.clear();
        window.setView(fixed);
        window.draw(sprite);
        window.display();
    }

    return EXIT_SUCCESS;
}

I'm sorry but I am just getting so frustrated at this frame stuff, how do all of you not have problems with stuff like this?

13

Graphics / Re: texture.update(pixels), using std::vector of Uint8 instead of array

« on: July 17, 2014, 04:40:40 am »

Thanks for the reply, I found a solution to the original problem at http://en.sfml-dev.org/forums/index.php?topic=14323.msg100700#msg100700

Code: [Select]

mTexture.update(&pixels[0]);
Not sure what you mean by "using" sf::Image. I hadn't used sf::Image like that before, you'd still need to make a texture and sprite to display it anyway, no?

14

Graphics / texture.update(pixels), using std::vector of Uint8 instead of array

« on: July 17, 2014, 03:49:49 am »

After reading http://sfml-dev.org/documentation/2.0/classsf_1_1Texture.php usage examples and http://en.sfml-dev.org/forums/index.php?topic=11900.msg82631

You should really not use new[] and delete[]. Take std::vector instead.

I am trying to display an image from a set of pixel data from an old file format (width*height values, ranging from 0-255, mapped to a 256-color palette, the details aren't relevant).

My code won't compile if I attempt to use an std::vector.

As in, this compiles

Code: [Select]

        mTexture.create(width, height);
        mSprite.setTexture(mTexture, true);

        sf::Uint8* pixels = new sf::Uint8[width * height * 4];
        for (int i = 0; i < width*height; i+=4)
        {
            //TODO: Change to the palette mapping...
            pixels[i] = colors[i];
            pixels[i+1] = colors[i];
            pixels[i+2] = colors[i];
            pixels[i+3] = 255;
        }
        mTexture.update(pixels);
        delete[] pixels;

but it doesn't if I try to change it to an std::vector...

Code: [Select]

        mTexture.create(width, height);
        mSprite.setTexture(mTexture, true);

        std::vector<sf::Uint8> pixels(width * height * 4);
        for (int i = 0; i < width*height; i+=4)
        {
            //TODO: Change to the palette mapping...
            pixels[i] = colors[i];
            pixels[i+1] = colors[i];
            pixels[i+2] = colors[i];
            pixels[i+3] = 255;
        }
        mTexture.update(pixels);


What should I be doing instead to avoid using new and delete[]? It looks like the usage example in the docs is using a dynamically allocated array

Code: [Select]

sf::Uint8* pixels = ...; // get a fresh chunk of pixels

15

General / Re: Processor usage, using the Intro's fixed timestep code

« on: July 15, 2014, 03:57:08 am »

I figure I'd bump this topic instead of creating a new one:

So I've been making a game. From the start, it seemed like the movement was ever so slightly choppy, but I ignored this and kept adding onto it, making sure to keep the timestep stuff separate from other parts of the program so that I could one day fix it. But I don't want to ignore it anymore, so I made this example to show the choppy movement I am talking about.  It's set up very similar to the SFML intro.

Example of jittery movment (may be hard to see in this, I tried to show it by turning off the window.clear() function while the player moves diagonal)

Here is the compilable code:
http://pastebin.com/wSUN2DxJ

It might not look like much, and for now it really isn't, but is there way to change my timestep so that it doesn't get these slight "jumps" in the otherwise smooth movement?

From the fix your timestep article:

This causes a subtle but visually unpleasant stuttering of the physics simulation on the screen known as temporal aliasing.

Is this what's happening here? Should I bother to try to implement "interpolation" for something that doesn't need really accurate physical timing?

This is asking a lot, but if anyone would try to compile the above code (I tried to make it minimal) and see if they get instances of jittery movement, I would appreciate it! And also, if you know a good solution =) It it just saddening when my code has this weird movement, but other games I've played run so smooth comparatively.