No display in renderTarget?

[CombatWombat]

I'm trying to implement a more "general" renderer that can draw to either a renderWindow OR a renderTexture.

So I inherit from something like:

class IRenderer
{
public:
    virtual void Render(sf::RenderTarget &rt) = 0;
};

I'm lead to believe I must call "display()" after drawing...

This function updates the target texture with what has been drawn so far. Like for windows, calling this function is mandatory at the end of rendering. Not calling it may leave the texture in an undefined state.

This leads to a problem, because my inherited renderer cannot call "display()" because it is not a virtual method in RenderTarget (it is contained in both RenderTexture & RenderWindow separately).

Is my entire architecture kind of wonky?  I sorta thought having a generic renderer that can just "RenderThisListOfThings" on "ThisRenderTarget" would be pretty versatile.

[binary1248]

This is because RenderTargets don't support the notion of "displaying". As its name implies, it serves as an interface for objects that can serve as targets for draw operations. How the contents that have been drawn are displayed in the end, whatever that might mean, is not part of the interface. As an example, a RenderWindow inherits its display() from Window which in turn performs a buffer swap to present the drawn contents to your screen. A RenderTexture on the other hand (when using the FBO implementation) doesn't do anything except call glFlush() when you call display().

If you have to rely on calling display() from your IRenderer interface, then something is not right when your design. A renderer would merely draw to its target and no more. Leaving the display() call to the code that actually instantiates and thus owns the RenderWindow or RenderTexture is the better way of doing things. After all, drawing might not be limited to your renderer. There might be others who want to draw as well, and prematurely calling display() before the complete frame is rendered is not recommended.

[zsbzsb]

Another thing, why would you try to design your own interface when SFML already provides sf::Drawable?

[CombatWombat]

A renderer would merely draw to its target and no more. Leaving the display() call to the code that actually instantiates and thus owns the RenderWindow or RenderTexture is the better way of doing things. After all, drawing might not be limited to your renderer. There might be others who want to draw as well, and prematurely calling display() before the complete frame is rendered is not recommended.

This is probably a better way of doing it, I suppose.  I'm still a little bleary on my implementation details so I can't say for sure.

Let me think out loud for a moment:
A likely reason to use a renderTexture is to create something like a light map which is drawn "off screen".  Is this correct?
So then you can take this off-screen texture, bind it to a sprite, and draw it (with blending) over/with the actual renderWindow contents.  Still on track?

My concern is passing around "unfinished" renderTextures to the final blending/mixing operation.  Whoever calls that operation needs to know to "finish/display" the renderTexture before it does the final display.

Another thing, why would you try to design your own interface when SFML already provides sf::Drawable?

I'm doing the bit that takes a sorted list of sf::Drawables and actually does the state setting and calling of draw() to a given target.

This is the first time I'm trying to do something that isn't just a hard coded blob of draw calls.