SFML community forums
Help => General => Topic started by: programmerGuy on August 07, 2013, 10:29:53 pm
-
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?
-
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.
-
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. Would you consider allowing anything that has draw(sf::RenderTarget&,sf::RenderStates) method to draw itself without inheriting sf::Drawable?
For what?
-
No added size, virtual call and const. Okay, it makes no sense and it can be done with global function. Sorry.
-
Thanks for the answer! Cleared up the confusion.
-
Most of the other member functions you mentioned are now available in the base class sf::Transformable.