Derive from sf::Drawable?

[programmerGuy]

The question of whether you should derive a class that draws something from sf::Drawable or give it a separate draw function has already been asked before.

This:

window.draw(menu)

or:

menu.draw(window)

However, I haven't seen this discussion for SFML 2.0 and higher. In SFML 1.6 the sf::Drawable class had things like:
- set/get position
- set/get rotation
- set/get scale
- set/get color
- set/get blend mode

And if it made since to have these in your class then you would derive from sf::Drawable, but now(in 2.0+) the drawable class just has a single draw function.

So should you always just derive from sf::Drawable if your class draws something? Or am I missing something else?

[Laurent]

Since there's only the draw function in SFML 2's sf::Drawable, the only difference is the syntax, as you already noticed.

This:

window.draw(menu)

or:

menu.draw(window)

So there's no strong point in favor or against deriving from sf::Drawable, it's just a matter of personal taste. It's not going to have a noticeable impact on your design either.

And all the transformation stuff that was also in sf::Drawable in SFML 1.6, is now in sf::Transformable.

[FRex]

Laurent. Would you consider allowing anything that has draw(sf::RenderTarget&,sf::RenderStates) method to draw itself without inheriting sf::Drawable? Although with your coding standard it'd add another file to sf::RenderTarget.

[Laurent]

Laurent. Would you consider allowing anything that has draw(sf::RenderTarget&,sf::RenderStates) method to draw itself without inheriting sf::Drawable?

For what?

[FRex]

No added size, virtual call and const.  Okay, it makes no sense and it can be done with global function. Sorry.

[programmerGuy]

Thanks for the answer! Cleared up the confusion.

[Nexus]

Most of the other member functions you mentioned are now available in the base class sf::Transformable.