Messages

1

Feature requests / Re: Aggregating Drawable and Transformable for Polymorphic behavior

« on: May 26, 2014, 07:42:30 pm »

Yes, absolutely, I'm gonna need to add a new layer of abstraction, but given the nature of the ECS (Entity-Component-System) approach, this will be a rather unconventional layer.

This class will be part of the Graphics component. I an ECS framework, it's wise to keep components as close to being POD (plain old data) as possible. Certainly, I am going to need to implement inner methods that manage the duality of the Drawable/Transformable object inside the component, but all of this should be invisible to the rest of the engine.

That is, I should be able to do both

sf::Sprite s; graphicsComponent.node = &s;

and

sf::Shape s; graphicsComponent.node = &s;

Calls like

graphicsComponent.node.setPosition(x,y) = &s;

might be unavoidable, but I can live with that.

An update method won't be necessary, for all of the logic is managed elsewhere.

2

Feature requests / Re: Aggregating Drawable and Transformable for Polymorphic behavior

« on: May 26, 2014, 07:21:01 pm »

Thanks for the suggestion, Hiura. I think I'm going to end up doing something along that line. Using some of the features offered by C++ for type definition I think I can hide the fact that it's a wrapper rather than a parent class.

If I come up with something decent I'll share it here.

3

Feature requests / Aggregating Drawable and Transformable for Polymorphic behavior

« on: May 26, 2014, 06:14:48 pm »

I am writing an engine for a 2D platformer based on an entity-component-system approach using SFML. Until now, I had a Graphics component with a pointer to sf::Sprite. This sf::Sprite would get drawn by the Rendering System on each update.

Recently I realized that I might want to draw other kinds of elements (Shapes and Text) during gameplay, ideally without changing the Rendering System. So, instead of a pointer to sf::Sprite, I decided that the Graphics component should have a pointer to sf::Drawable. The problem is that in order to draw these elements in the right location I need to invoke their setPosition() method. This is not possible polymorphically because that method belongs to class Transformable.

This could be easily solved. We could have a new class, say Node, that inherits from Drawable and Transformable and stands above Shape, Sprite and Text on the hierarchy.

class Node : public Drawable, public Transformable {

}
 

Instead of inheriting from Drawable and Transformable, classes Shape, Sprite and Text would then inherit from Node.

class SFML_GRAPHICS_API Shape : public Node{
//...

class SFML_GRAPHICS_API Sprite : public Node{
//...

class SFML_GRAPHICS_API Text : public Node{
//...

 

This way, the Graphics component can hold a pointer to sf::Node, which can behave polymorphically as a Shape, a Sprite or Text, exposing the properties that they have in common as subclasses of Drawable and Transformable.

Of course, the drawback is that I have to modify the code of SFML itself. I've tested it and so far I've found no problems, but you can never be sure...

So the questions are:

• Do you think this is a good solution?
• Could this change to the source code bring problems that are not evident at first sight?
• Would this be a good addition to the SFML Graphics architecture?

Edit: I just saw that a very similar proposal was posted here: http://en.sfml-dev.org/forums/index.php?topic=14157.msg99316#msg99316
What eXpl0it3r proposes might be a good alternative, although it could take gymnastics to implement cleanly in an entity-component framework.