RenderImage doesn't work

[ritave]

Hello again, I come here with another problem - the renderimage doesn't seem to draw anything.
In this minimal example we're supposed to see black window, with green rectangle (renderimage clear) with a red rectangle in it (renderimage draw).
But all I see is black screen...

Spec:
Linux with Arch Distribution
Msi wind u120 - intel integrated graphics
Sfml2
Drivers updated daily
RenderImage::IsAvailable() returns 1

Code: [Select]


#include <SFML/Graphics.hpp>

int main()
{
sf::RenderWindow Window(sf::VideoMode(100,100), "");
sf::RenderImage Image;
Image.Create(50,50);

while (true)
{
sf::Event Event;
while (Window.GetEvent(Event)) {}

Image.Clear(sf::Color(0,255,0));
Image.Draw(sf::Shape::Rectangle(0,0,25,25,sf::Color(255,0,0)));
Image.Display();

Window.Clear();
sf::Sprite Temp;
Temp.SetImage(Image.GetImage());
Window.Draw(Temp);
Window.Display();
}
}


Probably important edit:
I played a bit with valgrind (profiler, memory check etc.)
And it found that there are a few uninitialized variables used at this line:

Code: [Select]


Image.Draw(sf::Shape::Rectangle(0,0,25,25,sf::Color(255,0,0)));

errors profiler returned are:

Code: [Select]


==12276== Conditional jump or move depends on uninitialised value(s)
==12276==    at 0x4071948: sf::Renderer::SetShader(sf::Shader const*) (in /usr/lib/libsfml-graphics.so.2.0.0)
==12276==    by 0x40729B4: sf::RenderTarget::Draw(sf::Drawable const&) (in /usr/lib/libsfml-graphics.so.2.0.0)
==12276==    by 0x8049476: main (Temp.cpp:15)
==12276==
==12276== Conditional jump or move depends on uninitialised value(s)
==12276==    at 0x4071786: sf::Renderer::SetBlendMode(sf::Blend::Mode) (in /usr/lib/libsfml-graphics.so.2.0.0)
==12276==    by 0x4057AD1: sf::Drawable::Draw(sf::RenderTarget&, sf::Renderer&) const (in /usr/lib/libsfml-graphics.so.2.0.0)
==12276==    by 0x40729C7: sf::RenderTarget::Draw(sf::Drawable const&) (in /usr/lib/libsfml-graphics.so.2.0.0)
==12276==    by 0x8049476: main (Temp.cpp:15)
==12276==
==12276== Conditional jump or move depends on uninitialised value(s)
==12276==    at 0x4071898: sf::Renderer::SetTexture(sf::Image const*) (in /usr/lib/libsfml-graphics.so.2.0.0)
==12276==    by 0x4075994: sf::Shape::Render(sf::RenderTarget&, sf::Renderer&) const (in /usr/lib/libsfml-graphics.so.2.0.0)
==12276==    by 0x4057AE4: sf::Drawable::Draw(sf::RenderTarget&, sf::Renderer&) const (in /usr/lib/libsfml-graphics.so.2.0.0)
==12276==    by 0x40729C7: sf::RenderTarget::Draw(sf::Drawable const&) (in /usr/lib/libsfml-graphics.so.2.0.0)
==12276==    by 0x8049476: main (Temp.cpp:15)
==12276==
==12276== Conditional jump or move depends on uninitialised value(s)
==12276==    at 0x40718D2: sf::Renderer::SetTexture(sf::Image const*) (in /usr/lib/libsfml-graphics.so.2.0.0)
==12276==    by 0x4075994: sf::Shape::Render(sf::RenderTarget&, sf::Renderer&) const (in /usr/lib/libsfml-graphics.so.2.0.0)
==12276==    by 0x4057AE4: sf::Drawable::Draw(sf::RenderTarget&, sf::Renderer&) const (in /usr/lib/libsfml-graphics.so.2.0.0)
==12276==    by 0x40729C7: sf::RenderTarget::Draw(sf::Drawable const&) (in /usr/lib/libsfml-graphics.so.2.0.0)
==12276==    by 0x8049476: main (Temp.cpp:15)
==12276==
==12276== Conditional jump or move depends on uninitialised value(s)
==12276==    at 0x4071948: sf::Renderer::SetShader(sf::Shader const*) (in /usr/lib/libsfml-graphics.so.2.0.0)
==12276==    by 0x40729B4: sf::RenderTarget::Draw(sf::Drawable const&) (in /usr/lib/libsfml-graphics.so.2.0.0)
==12276==    by 0x804952A: main (Temp.cpp:21)
==12276==
==12276== Conditional jump or move depends on uninitialised value(s)
==12276==    at 0x4071786: sf::Renderer::SetBlendMode(sf::Blend::Mode) (in /usr/lib/libsfml-graphics.so.2.0.0)
==12276==    by 0x4057AD1: sf::Drawable::Draw(sf::RenderTarget&, sf::Renderer&) const (in /usr/lib/libsfml-graphics.so.2.0.0)
==12276==    by 0x40729C7: sf::RenderTarget::Draw(sf::Drawable const&) (in /usr/lib/libsfml-graphics.so.2.0.0)
==12276==    by 0x804952A: main (Temp.cpp:21)
==12276==
==12276== Conditional jump or move depends on uninitialised value(s)
==12276==    at 0x4071898: sf::Renderer::SetTexture(sf::Image const*) (in /usr/lib/libsfml-graphics.so.2.0.0)
==12276==    by 0x40768C7: sf::Sprite::Render(sf::RenderTarget&, sf::Renderer&) const (in /usr/lib/libsfml-graphics.so.2.0.0)
==12276==    by 0x4057AE4: sf::Drawable::Draw(sf::RenderTarget&, sf::Renderer&) const (in /usr/lib/libsfml-graphics.so.2.0.0)
==12276==    by 0x40729C7: sf::RenderTarget::Draw(sf::Drawable const&) (in /usr/lib/libsfml-graphics.so.2.0.0)
==12276==    by 0x804952A: main (Temp.cpp:21)


==12276== is a process number, so you shouldn't worry about that.
As you can probably see the rest are callstacks.

I hope it helps you somehow

[Laurent]

It works for me on Windows, so it might be a driver issue.

The valgrind output is ok, the uninitialized values are protected with a boolean flag, and they are only used when this flag says they are initialized.

However I noticed a little potential issue with this code, and changed it a little bit. You can try the latest revision, but it shouldn't change anything for you.

[mistagiggles]

I am also having the same problem with RenderImage.

Ubuntu 10.10
SFML2
RenderImage::IsAvailable() returns 1
Using the standard intel drivers

I have not been able to test my code on a windows machine, but I am quite sure that my code is correct and the problem is either with drivers or sfml.

[Dominator]

intel integrated graphics
RenderImage::IsAvailable() returns 1

RenderImage::IsAvailable() returns 1
Using the standard intel drivers

Same problem here:
Arch linux, intel drivers, RenderImage::IsAvailable() returns 1, but no visible renderimages.

I tested the same code on a windows machine and another linux machine, both with nvidia graphics and no problems there.

So it's very likely to be an issue with the linux intel drivers.  :cry:

[Groogy]

While developing the rbSFML bindings I noticed on my laptop that has integrated intel graphics that it freaked out completely. Might be related, haven't tried doing a RenderImage though.

I have a guess that just like with ATI that Intel don't like the global context and freaks out somehow there without crashing the application. (When looking at rbSFML for instance, I found Intel fiddling with stuff that crashed ruby and got hell look like a nice summer place). With rbSFML on the laptop I currently can't draw any text but on any proper graphic card, it works smoothly like it should, even in a virtual host environment(both on the laptop and on another computer).

[Dominator]

I looked further into this issue and found out that neither the FBO method nor the P-buffer method work, but both claim to be supported.

The FBO method is used by default and there is no console output, but when I forced the P-buffer method to be used I got the following message:

Code: [Select]

Impossible to create render image (failed to match the requested size). Size: 0x0 - Requested: 160x120

Looks like I'll have to switch back to SDL if this can't be fixed.
At least it is more hardware independant compared to SFML with it's current issues with ATI and Intel graphics... :?

[Groogy]

That's because SDL have the SDL_Init and SDL_Quit, while SFML originally was designed to do those things for you. Though Laurent is currently changing that so you have to explicitly initiate SFML just like in SDL.

And with the Intel problems I had, that is not associated directly with SFML, it was ruby that freaked out as Intel removed objects from memory while Ruby's garbage collector tried to mark-sweep them. Or something like that, I am not entirely sure. What I do know for a fact is that it's Intel's new GEM on Linux that screws it all over.

[Laurent]

That's because SDL have the SDL_Init and SDL_Quit, while SFML originally was designed to do those things for you.

Well, this is not the reason. The actual reason is that SDL doesn't use OpenGL
It has no RenderImage, everything happens on the CPU so drawing a sprite to an off-screen surface ends up to a simple pixel copy.

[l0calh05t]

pretty sure it's a driver problem. intel graphics chips have incredibly crappy opengl support. on my previous laptop, whenever blending was enabled, all colors were inverted (and it didn't blend  :roll: )

[Gibgezr]

It's not just Intel or ATI chipsets that seem to have issues with RenderImages, I recently found RenderImages glitching out on NVidia 8800 cards with latest (and older) drivers. The same code works fine on other cards I have tested it with, but the 8800's cause occasional random errors in the updating of the RenderImage. I can hack a fix in by simply calling RenderImage.Display() after every single call to RenderImage.Draw(), instead of waiting until all draws are done. The error may be related to non-overlapping blits performed where both source and destination are RenderImages, and may or may not matter if they are the same RenderImage (I have to test a bit to narrow down the culprit blits).

Currently, RenderImages seem a wee bit buggy.

[Laurent]

They are. After the ATI fix is done, I'll work on them -- I already have a bunch of bug reports about them