Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Before when using inheritance, I could draw all my objects using this recursive function:

void Object::innerDraw(sf::RenderTarget& target, sf::RenderStates states)
{
    states.transform *= Object::getTransform(); //translate by this object's position
    this->Draw(target, states); //draw this object
    for (Object *child : m_children)
    {
        if(child->isVisible)
            child->innerDraw(target, states); //draw all children
    }
}

However, I am now looking at a component design where the graphics component pushes it's sprite to the renderer Renderer::toDraw.push_back(&sprite);

The renderer then draws all the sprites in it's container

for (sf::Drawable *Entity : toDraw)
{
    target.draw(*Entity, state); // (state isn't doing any transforming here)
}

How can I be able to draw things relative to parents position?

share|improve this question
    
Can't you just reference parent components using an interface (e.g. ITransformParent) to keep coupling low? –  Den Jan 27 '13 at 12:20
    
@Den, if the code/concept doesn't work, coupling is really the last thing to worry about. –  snake5 Jan 27 '13 at 12:28
    
I dont know what you are doing in that second piece of code but. Transform component in Unity, can have parent Transform on it. So when you go through sprite components, you get transform component, that can have absolute position in it. –  Kikaimaru Feb 26 '13 at 12:13
add comment

4 Answers

Component-based entity systems are often about removing inheritance of type (and providing a nice means to drive things from data, although that aspect of things is not particularly relevant to this question).

That is, not having a very deep class hierarchy where everything in your game (tanks, bullets, space ships, whatever) exist in one large "family tree" of classes. It does not mean you need to remove logical parent/child relationships from your game.

In this case, you can implement the kind of hierarchical transformation approach in exactly the same way, either by having the renderable components have a transformation hierarchy themselves or simply having the renderable components contain a reference to a sprite which uses the existing transform hierarchy you outlined in your question -- this, in fact, would let you keep the bulk processing logic for those components in your renderer itself, where is could be in general more localized/cache-coherent and potentially better for parallelization (unlikely with rendering, but usually true for other subsystems or the subsystems themselves). See also the outboard component architectural approach.

share|improve this answer
add comment

You most probably need a complex transform state tree/cache system. You can start by adding a "parent" member to the transform object. Implementation pretty much depends on what you already have there so there's not much I can help with.

OR

You could go back to a system where you know how it's done (at least to that part of it). Why did you move away from it?

share|improve this answer
2  
I moved away because I wanted to try a component system - just wanted to learn how to use it. –  andrew Jan 27 '13 at 10:25
    
It's generally better to try and evaluate things in very small projects before moving them into bigger ones. If this already is a small project, you'll just have to find a way to fix it or get back to the real thing. –  snake5 Jan 27 '13 at 12:27
add comment

The easiest and most obvious way will work well enough:

Make a "parent relationship" component and attach it to your entities. Then in the transform calculation step, recursively calculate the parent transform.

If you want to improve efficiency, save a time stamp or frame counter with the parent entity so that you don't need to compute the parent transform more than once per frame.

share|improve this answer
add comment

I've got the feeling you might be misinterpreting what a component-system is about.

Here is an excellent article about this.

An ECM-system is meant to avoid the child-parent spaghetti between code-objects that inherit from each other, not between game-objects.

This has nothing to do with transforms. If you have a character and you want to move his head in relation to the body, you still need some form of parent/child relationship between them and a scene-graph or transform-stack that couples their position and orientation together.

For your example you could rewrite your renderer to apply the transforms itself and call *push_back* like this

void Object::innerDraw(sf::RenderTarget& target, Transform & parentTransform)
{
    Transform myTransform = parentTransform * Object::getTransform();
    Renderer::toDraw.push_back(&sprite, myTransform);
    for (Object *child : m_children)
    {
        if(child->isVisible)
            child->innerDraw(target, myTransform); //draw all children
    }
}

But I would probably prefer to keep it as it is and not.

(Note, that Transform is just a guess, I don't know how they're actually called in SFML)

share|improve this answer
    
You're misinterpreting the point of E/CS - it is meant for data-driven game object behavior composition. If being data-driven isn't necessary (and it usually isn't), simple composition is more than enough. –  snake5 Feb 26 '13 at 11:17
    
I'm not saying anything about EC being necessary here or not. I'm saying, EC doesn't absolve you from having to relate in-game objects if you want to draw them in their right position. (obviously I might still be wrong about the inheritance-spaghetti thing, in which case: sorry) –  Jan Feb 26 '13 at 14:21
    
Yeah, I was just taking about that "inheritance vs. ECS" part. You're right about transforms being a different/another problem. –  snake5 Feb 26 '13 at 17:15
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.