Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: sf::Sprite in a component-based system  (Read 1001 times)

0 Members and 1 Guest are viewing this topic.

Shodan

  • Newbie
  • *
  • Posts: 1
    • View Profile
sf::Sprite in a component-based system
« on: May 10, 2014, 09:47:58 pm »
Hi,

first post. *waves*  :D

I've been reading some blog-posts on how to implement component-based entity systems. I like the concept, especially since I toyed with a similar, though much more flawed, inheritance-based idea.

However, there's a slight problem I'm not sure how to deal with;

Every entity needs a position, but not every entity needs to be drawn/drawable. Therefore, I would like to encapsulate the latter into a component that I can add to an entity, should it have to be rendered. Sure, I could just add a Sprite to the component but as I said, the position should be defined in the entity. Adding a Sprite, therefore having two positions, seems redundant. In addition to that, I'd have to write extra code just to synchronize them. Add a physics component and it becomes even more messy, requiring the Sprite to know about the changes that just occured in the entity - only to keep itself in sync. ::)

Any Ideas?


Ixrec

  • Hero Member
  • *****
  • Posts: 1241
    • View Profile
    • Email
Re: sf::Sprite in a component-based system
« Reply #1 on: May 10, 2014, 09:55:00 pm »
Well, duplicating the position wouldn't be a travesty.  For a first implementation you might be better off just using a sprite and not worrying about it.

As for alternatives, an sf::Sprite is actually an extremely simple object:
class SFML_GRAPHICS_API Sprite : public Drawable, public Transformable
{
...
    Vertex         m_vertices[4]; ///< Vertices defining the sprite's geometry
    const Texture* m_texture;     ///< Texture of the sprite
    IntRect        m_textureRect; ///< Rectangle defining the area of the source texture to display
};
 
so one option is to split the sf::Sprite into these three "components", and handle each of them yourself.  Of course, that means duplicating a lot of the logic in sf::Sprite, and making your draw() calls a bit more complicated, but if you really want to avoid duplicating the position data, this is an option.

Veritas

  • Jr. Member
  • **
  • Posts: 79
    • View Profile
    • Email
Re: sf::Sprite in a component-based system
« Reply #2 on: May 10, 2014, 11:14:18 pm »
 You can simply use sf::Sprite in your renderer's routine:


        sf::Sprite sprite;

        sprite.setTexture(entity.getGraphicsComponent.texture);

        sprite.setPosition(entity.GetPhysicsComponent.position);

        sprite.setRotation(entity.GetPhysicsComponent.rotation);

        mWindow.draw(sprite);

 

At this point you don't really need the GraphicsComponent to hold much. You may want to keep the texture reference in it but as long as it specifies whether the entity must be rendered, it fulfills it's purpose.
« Last Edit: May 10, 2014, 11:39:08 pm by Veritas »
"Lasciate ogni speranza, voi ch'entrate"

 

anything