[Solved] PNG refuses to draw

[Qix]

Having a hell of a time getting this PNG to draw. Certain code blips have gotten it to draw in the past, but I've since re-written a large portion of the code and it's refusing to work. I've followed all the tutorials and looked at a ton of issues posted on the forum. The code just seems right, but it won't work.

Png class that extends `sf::Sprite`

RGPng::RGPng(string path)
{
        // Store
        _path = path;
        //setPosition(0, 0);

        // Create image
        if(!_image.loadFromFile(path))
        {
                // Throw
                throw new RException("Could not load PNG image '%s'", path.c_str());
        }

        // Create texture
        _tex.loadFromImage(_image);

        // Load into sprite
        setTexture(_tex, true);

        sf::IntRect r = getTextureRect(); // Confirmed; 0,0, correct w, correct h
}
 

Code that extends another drawable (debugging confirms this is being called)

RGPng* png; // = new RGPng("test.png");

// The SFML 'draw(target,states)' method calls this.
void OnDraw(sf::RenderTarget& target, sf::RenderStates states) const
{
        target.draw(*png);
}
 

And then the window's draw code (which eventually draws the above object)

void Draw()
{
        // Are we open?
        if(!isOpen() || !this) return;
       
        // Draw
        setActive(true);
        pushGLStates();
        clear(_(RIT_THEME, R_THEME)->Window.BaseColor);
        draw(*_manager);
        display();
        popGLStates();
        setActive(false);
}
 

Fraps is confirming I have ~30 FPS, so it's definitely being updated. I've also successfully drawn a simple triangle to the window using the same architecture in my program. Everything works fine up until I try to get this PNG to display.

Again, This PNG has worked just fine with SFML in past versions of the code before the engine was re-written.

Am I missing a fundamental idea behind the texture/sprite system? Am I missing a step?

[Qix]

So I've narrowed it down; when the PNG wrapper is loaded as a class member and I try to draw it, it doesn't draw. However, if I (for testing purposes) create a new object every frame that loads the image, it works just fine.

Still trying to figure this out; to be perfectly honest the `const` on the `draw()` method is really, really annoying.

EDIT: It seems to be the issue with using `draw()` with subclassing the sf:Drawable class. I'll implement my own drawable...

Kinda seems weird that there isn't an easier way to do this in SFML, but it's good enough!

[Laurent]

Can you please show a complete and minimal code that reproduces the problem? It's hard to help with fragments of a big projects; from what you show, there's no obvious error.

[eXpl0it3r]

Btw it's not really advised to derive from sf::Sprite.
Also is there a reason for loading the image and copy it to a texture manually? I mean texture.loadFromFile() does that automatically.
But like Laurent said we can't help with those few code pieces.

[Qix]

Btw it's not really advised to derive from sf::Sprite.
Also is there a reason for loading the image and copy it to a texture manually? I mean texture.loadFromFile() does that automatically.
But like Laurent said we can't help with those few code pieces.

Yea I noticed that I had the wrong version of the test code in there. That was for testing. The code before / after testing this out was just the texture.loadFromFile().

I figured it out; Sprites lose their reference to Textures when being referenced from a const method (such as draw). Drawing them with a direct reference to a RenderTarget and outside of a const method (especially the draw() method) works as expected.

[Laurent]

I figured it out; Sprites lose their reference to Textures when being referenced from a const method (such as draw). Drawing them with a direct reference to a RenderTarget and outside of a const method (especially the draw() method) works as expected.

That doesn't make any sense. Sprites can't magically "lose" the pointer to their texture, especially in a const member function.

This is most likely a side effect of a problem in your code/design.

[Qix]

You're right. After I posted that I realized it made no sense. Just stripped all of my project code and created a window + sprite/texture from scratch. It must be something on my end.

It doesn't matter really, I'm stripping the graphics functionality out of the entire project and starting that portion over. There is still a lot of hierarchy left over from when I was using SDL.

[Nexus]

You should not allocate exception objects dynamically. Generally, avoid new and delete as much as possible.

By the way, if you had minimized your problem first, you would have come across the error directly

[Qix]

I found the issue.

I wasn't de-activating the window in the main thread before having the worker thread work on it.

It wasn't until I took a few lines out that the built-in "Could not activate windows context" errors started flooding the console.

Added a setActive(false) to the window manager (that sits on the main thread) and everything worked peachy.

[eXpl0it3r]

It wasn't until I took a few lines out that the built-in "Could not activate windows context" errors started flooding the console.

That's exactly why we always say: 'Can you please show a complete and minimal code that reproduces the problem?' So people got and minimize their code and very often in doing so they find their errors on their own...
That's what 'bug hunting' is all about, throwing out stuff that hasn't anything to do with it and narrowing the problem in until the code is so small that it's obvious.

[Qix]

It wasn't until I took a few lines out that the built-in "Could not activate windows context" errors started flooding the console.

That's exactly why we always say: 'Can you please show a complete and minimal code that reproduces the problem?' So people got and minimize their code and very often in doing so they find their errors on their own...
That's what 'bug hunting' is all about, throwing out stuff that hasn't anything to do with it and narrowing the problem in until the code is so small that it's obvious.

With what I had and the solution it was pretty difficult to do so with the project. I tried simplifying the code and it worked fine. That is why I didn't post it.