sfml rendertexture with intel gpu

[doingit]

I've read a few reviews about SMFL, in particular, sf::RenderTexture having some issues with older intel drivers, maybe this is applying towards me too? =(

GPU spec: (Displays interpretation)
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) 852GM/855GM x86/MMX/SSE2
OpenGL version string: 1.3 Mesa 10.1.3

    sf::RenderWindow window(sf::VideoMode(200, 200), "SFML works!");
    sf::CircleShape shape(100.f);
    shape.setFillColor(sf::Color::Green);
    sf::RenderTexture rt;
    sf::Sprite s;
    rt.create(200,200);
    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
        }
        rt.clear();
        rt.draw(shape);
        rt.display();
        s.setTexture(rt.getTexture());
        window.clear();
        window.draw(s);
        window.display();
    }
 

I've encounter an distorted graphics error on my larger project and decided to reproduce this "behavior" with the simple getting started code above; the changes were with drawing the shape first to renderTexture then to the renderWindow.

The resulting graphics behavior I am receiving is a single green line going vertically in the window; whereas you would normally get a green circle.

Help please.

My larger project is producing the same behavior. I would like to not avoid renderTexture; the larger project draws many objects to the screen and would be better off drawn on multiple render textures, with effects.

[ramaskrik]

The example runs just fine on my computer. Seems like it's a problem with the OpenGL:

OpenGL renderer string: Mesa DRI Intel(R) Ironlake Mobile
OpenGL version string: 2.1 Mesa 11.0.2

[doingit]

So... any recommendations / work-around?

I'm using OpenGL version 1.3 mesa 10.1.3, the latest on 14.0.4.3 LTS; I'm sure there are people using older versions than me...

Any advice on where to go from here on? I really need the power of renderTextures.

If I do manage to update my OpenGL version, will this behavior effect all of the users of my application who're on 1.3 or below?

Edit:
I think OpenGL version is based on hardware specs of GPU, version 1.3 seems to be my limit .

[ramaskrik]

I am not sure which version of OpenGL is meant to be supported by SFML (and was unable to find it). That is the difference between a bug and an unsupported feature (latter would mean that there is no workaround). Someone (maybe Laurent himself) could enlighten us here.

[Hapax]

There was an interesting discussion about an error with render textures here.
Have you tested the code there? Is it linked?

Which version of SFML are you using? Have you tried the latest master? It could well have been fixed.

[Mario]

This indeed looks like a render texture bug that's been fixed long ago (i.e. the top or bottom of the texture is stretched over the whole drawable). So it would be very important to know your SFML version. If possible, try to use 2.3.x.

[doingit]

I installed SFML a few weeks ago, using the instructions on the sfml/linux tutorial on the lubuntu cli.

sudo apt-get install libsfml-dev

I believe it should be a new-enough version.

Else, where can I determine the version value? I've read on google that it would be in the config.hpp file but I didn't see any version numbers.

[Hapax]

If it was a few weeks ago, it could be the latest release version. (Did you get it from here?)
However, some fixes may have been made since that release and the very latest source is available from SFML's GitHub.
You may find a pre-built version at the unofficial Nightly Builds but it comes highly recommended to build it yourself from the source.

[doingit]

Alright Hapax, thanks for the support!

I've got a pattern identified! thanks to the link you provided, I was able to cross test many of the code provided there (the ones without quick sprite).

It would seem that the behavior only occurs with renderTextures of sizes below 256*256; my 100*100200*200 illustration above created this phenomenon. SO as long as the renderTextures are above size 256*256, it works (Not sure why).

As to the version of SFML I am using and how I downloaded it: it was installed using the linux command line interface (cli) with the linux command line provided by SFML's website:

sudo apt-get install libsfml-dev

So, I think it should be up to date.
Now for the more interesting aspect, why does it not allow renderTextures of size smaller than 256 by 256(Update: one side can be smaller than 256, not both)?
I will be testing more..

Edit 1:
It would seem that atleast one dimension of the two, for renderTexture, must be atleast 256.
Have a renderTexture of 10*256 causes me no strange behavior, however if any of the sides were less than 256, say 255, then unknown behavior occurs.
Edit 2:
The size of the shape is irrelevant, if the shape is larger than the renderTexture, it just gets drawn out of the renderTexture like normal.
Edit 3:
The clear method of renderTexture still works at lower sizes, clearing with a color of red will produce a red clearance like normal, but the shape will be missing or distorted; I've only seen missing and single vertical line so far.
Edit 4:
Sprites on renderTextures smaller than 256 also do not behave like normal.

Does this apply to you as well? if not, is there any difference between sfml's implementation of renderTextures dependent on size and OpenGL version? If not then, worst case, it's probably just an OpenGL 1.3 issue.

Maybe I can use larger renderTextures (not saying I can't) and simply use sprites to subRect smaller images from the renderTextures, haha.

My reason for using small renderTextures:
I was using smaller renderWindows originally so I complemented it with smaller renderTextures; but I can work around it with sprites and subRects of the larger renderTexture to fit my needs.

It is interesting though, that small renderTextures behave differently on OpenGL 1.3 or is it for all OpenGL? And that larger renderTextures are no effected at all.

[Hapax]

It would seem that the behavior only occurs with renderTextures of sizes below 256*256; my 100*100200*200 illustration above created this phenomenon. SO as long as the renderTextures are above size 256*256, it works (Not sure why).

Have you tried some obvious specific sizes, like 128 x 128?

Personally, your example code worked for me but I'm using Windows, not Linux, and have an OpenGL version of approx. 4.5. As an aside, the code in the error discussion thread that I posted above worked for me, as you can see in the thread, but begun to fail after updating my drivers.
I'm not clear as to which version of SFML you are using. Did you download (from the SFML website) and install it, or download (from GitHub) the source and build it?

Does anybody know if this specific problem is fixed and on which branch (if it isn't merged yet)? Anyone have exactly the same problem with one version and not have it with another?

[ramaskrik]

I'm not clear as to which version of SFML you are using. Did you download (from the SFML website) and install it, or download (from GitHub) the source and build it?

He has mentioned several times he's got the SFML installed via apt-get from the Ubuntu package archives

(click to show/hide)

As to the version of SFML I am using and how I downloaded it: it was installed using the linux command line interface (cli) with the linux command line provided by SFML's website:

sudo apt-get install libsfml-dev

So, I think it should be up to date.

I installed SFML a few weeks ago, using the instructions on the sfml/linux tutorial on the lubuntu cli.

sudo apt-get install libsfml-dev

I believe it should be a new-enough version.

Does anybody know if this specific problem is fixed and on which branch (if it isn't merged yet)? Anyone have exactly the same problem with one version and not have it with another?

I am not sure, but it seems the same / a similar bug was fixed in 2.2 release (which the OP most likely doesn't have).

So... any recommendations / work-around?

I'm using OpenGL version 1.3 mesa 10.1.3, the latest on 14.0.4.3 LTS; I'm sure there are people using older versions than me...

You probably meant 14.04 LTS, right? (There's nothing like 14.0... version of Ubuntu) In that case, as you may see on the link I posted above, your version of SFML is most likely 2.1:

trusty (14.04LTS) (libdevel): Simple and Fast Multimedia Library - Development Files [universe]
2.1+dfsg-4ubuntu2: amd64 i386

The newest version, however, is 2.3.

[doingit]

You were both right, that I did not have the newest version; I wasn't aware myself and did not know that the command line installation wasn't up to date. I couldn't even determine what version I was on even though I had all the files ha ha.

Sorry for all the trouble, everything is working great now.

I'm still learning my way into linux, so I have a question... Does newer versions of (L)ubuntu provide different versions of SFML or are they all being distributed versions  < 2.2? Are all the repositories the same?

If they're all being distributed lower versions of SFML, this problem might occur again in the future because the SFML linux installation tutorial may be suggesting a not up to date version through the method of CLI installation.
http://www.sfml-dev.org/tutorials/2.3/start-linux.php

Choice #1: command line installation was preferred by the tutorial, for ease I understand.

Everything is fine now.
But, it'd be nice if the tutorial leaves a note stating which version should be expected, or heck, maybe have a builtin variable somewhere in the header that allows the user to print the value.

Example:

std::cout<<"The SFML version number is: "<<sf::Version::VALUE<<std::endl

A version number in the header, within the namespace Version and being a global const static variable called VALUE.

Thanks a lot everyone.

Edit:
Ubuntu Package Search
Interesting, it shows the version number on the Ubuntu Package Search.
I installed it using the tutorials from SFML so I was never aware of the version.
Knowing the version number would've helped a lot.

[Hapax]

Like this?

std::cout << SFML_VERSION_MAJOR << "." << SFML_VERSION_MINOR << "." << SFML_VERSION_PATCH << std::endl;

[doingit]

Yes like that   
Never knew that was available!

Should've mentioned it from the start! ha ha.

I read someone about it being in the header and saw that line of code, itself, in the header but never thought to had printed it through the console.

Thanks again.
Inquiry it next time if someone doesn't know their version please!