-
Hello,
I'm new to SFML and I'm trying to draw sprites with transparency (mostly to draw things on top of other things).
From the tutorials and forum topics I've browsed, I understand that PNG texture transparency should work without doing anything special.
Here is what I've done (slightly modified base tuto):
#include <SFML/Graphics.hpp>
int main()
{
sf::RenderWindow window(sf::VideoMode(200, 200), "SFML works!");
sf::Texture myTexture;
myTexture.loadFromFile("./textures.png");
sf::Sprite mySprite;
mySprite.setTexture(myTexture);
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(mySprite);
window.display();
}
return 0;
}
And when I run it, at the places where my texture is transparent I see a white rectangle instead of the blue background. I'd like the background (or anything drawn before) to be displayed through the transparent parts of the image. I have tried various PNG images with no success.
Did I do something wrong or miss anything? Is this a bug/config problem on my end?
I'm running the git version of SFML compiled by hand on debian on a virtual machine (3d acceleration working, no direct rendering) and with an ATI radeon 6950.
Any help is welcome :)
EDIT: my problem was solved (see my last post below) and was VirtualBox-related.
-
At least your code is OK. Could you give us one of your PNG?
Maybe your drivers aren't up to date, or it's a virtual machine related problem. (= I don't know :p )
-
Thanks for the quick answer.
Here is a PNG texture. I've tried with several PNGs including random ones from the web and it works with none.
-
Using your source code and image without any modifications, it runs perfectly for me:
(http://i.imgur.com/T0GD8fM.jpg)
A screenshot of your problem occurring may help.
-
Here is a screen of what I get (attachment).
Since it runs fine for you it's probably driver/opengl/virtualbox/thing - related. I'll look into that. Any idea is welcome :)
-
export LIBGL_ALWAYS_INDIRECT=1
That line is most likely the source of the problem. Doing a little research, it seems that it drops OpenGL support back to 1.4 (lots of information on it here (http://unix.stackexchange.com/questions/1437/what-does-libgl-always-indirect-1-actually-do)), and I believe SFML needs at least OpenGL 2.0. Can you add the following line to your code and report back the results.
sf::ContextSettings settings = window.getSettings();
std::cout << "version:" << settings.majorVersion << "." << settings.minorVersion << std::endl;
-
Seems you are right:
vlanore@vlanore-vm:~/zzbl/test$ ./test
Segmentation fault
vlanore@vlanore-vm:~/zzbl/test$ export LIBGL_ALWAYS_INDIRECT=1
vlanore@vlanore-vm:~/zzbl/test$ ./test
version:1.4
As exemplified by these commands I use LIBGL_ALWAYS_INDIRECT as a workaround to avoid insta-segfaulting on window creation. It seems though that it's too brutal and cripples SFML :/
Further investigation revealed the segfault is probably video-drivers-related and I'm currently in the process of trying to upgrade them to the latest possible version. I'm hoping that avoiding the LIBGL_ALWAYS_INDIRECT workaround will fix my transparency problem.
-
Okay I managed to make everything work. Latest VirtualBox version and guest additions didn't help but I discovered that instead of using LIBGL_ALWAYS_INDIRECT to avoid the segfault I could use LIBGL_ALWAYS_SOFTWARE which does not reduce OpenGL to 1.4.
Here is the result of the same code as the previous post:
vlanore@vlanore-vm:~/zzbl/test$ ./test
Segmentation fault
vlanore@vlanore-vm:~/zzbl/test$ export LIBGL_ALWAYS_SOFTWARE=1
vlanore@vlanore-vm:~/zzbl/test$ ./test
version:2.1
-
Okay I managed to make everything work. Latest VirtualBox version and guest additions didn't help but I discovered that instead of using LIBGL_ALWAYS_INDIRECT to avoid the segfault I could use LIBGL_ALWAYS_SOFTWARE which does not reduce OpenGL to 1.4.
Nice. Glad you solved your problem.
Just wanted to say that this helped me too on a VirtualBox VM where 3D passthrough does not work since the host doesn't have X.org >= 1.15 - your solution worked like a charm - thanks :)