SFML community forums

General => Feature requests => Topic started by: kubawal on January 16, 2014, 04:07:20 pm

Title: Drawable and Transformable class
Post by: kubawal on January 16, 2014, 04:07:20 pm

I think all drawable and transformable things could have the same parent class.
For example:

namespace sf
{
class Object
: sf::Drawable, sf::Transformable
{
};

// and all drawable and transformable classes derives it
// for exmaple:
class Sprite
: sf::Object
{
//...
};
 

I came up with this idea when i written SFML and Box2d framework, when I needed to write method returning drawable object which i can set it position.

Title: Re: Drawable and Transformable class
Post by: zsbzsb on January 16, 2014, 04:16:36 pm

And how would this help?  ???

Quote

returning drawable object which i can set it position.

Just return a sf::Transformable type... Or use a template  ;)

Changing the entire library just because it doesn't necessarily match your design is not the best idea. Maybe you should consider improving on your overall design.  8)

Title: Re: Drawable and Transformable class
Post by: kubawal on January 16, 2014, 04:23:30 pm

And how i can draw it?

win.draw(*((Drawable*)transformablePtr));

???

This is a very bad code, because i don't know whether transformablePtr is Drawable.

Title: Re: Drawable and Transformable class
Post by: zsbzsb on January 16, 2014, 04:29:00 pm

Separate your update code from your drawing code... And even better make your own object inherit from sf::Drawable

Title: Re: Drawable and Transformable class
Post by: eXpl0it3r on January 16, 2014, 04:42:38 pm

It would've been better to include the reason for such a request in the first post.

So here it is: It's cumbersome to have a container of sf::Transformable, because it requires additional tracking and casting to access the sf::Drawable functionalities. Or the other way around, it's cumbersome to have a container of sf::Drawable, because it requires additional tracking and casting to access the sf::Transformable functionalities. This is not issue for custom classes, but when it comes to reusing SFML's classes it won't work.
A class that aids as base class for Sprites and Shapes and combines Drawable and Transformable would make possible again to mix them all.

This was just to clarify what's going on here, since the OP didn't include the reasoning.

If you use anything like that in your code, make sure to give it a different name "object" is about as generic as you could ever get and nobody will understand what it actually is.

While I certainly see the issue, I'd say that your design might be flawed. I can't fully judge, since I didn't see your code. I generally wouldn't go with one container hold all objects that can be drawn or transformed, instead I'd most likely go with some sort of Entity class that has its own public API, that gets used inside the game, while the Entity itself holds a sprite/vertex array/shape and forwards the calls of its API to the inner drawable.
That way, it's easy to just create a container of Entity and you don't have to bother with Drawables and Transformables. But it really depends on what you do. ;)