Support children class in view

[buckle2000]

If I have a interface represent the graphics of an entity.

interface RenderComponent {
    function getDrawable():IBitmapDrawable;
}

and this implement:

class SpriteRenderComponent implements RenderComponent
{   
    public var target:Sprite;

    public function new() {
        target = new Sprite();
    }

    public function getDrawable():IBitmapDrawable {
        return target;
    }
}

and I create a view:

var v:View = new View([RenderComponent],null,context);

add an entity:

var e:Entity = context.entities.create();
e.set(new SpriteRenderComponent ());

But I can't get the SpriteRenderComponent using context.entities.
Also, this doesn't work either:

var e:Entity = context.entities.create();
e.set(cast (a,RenderComponent));

I found that it is related to some methods in ComponentManager.hx.

Anyway, am I supposed to do this, does it volatile the concept of ECS?

[PDeveloper]

I don't know why I didn't see this before! Sorry for being so late.

What is your purpose in extending the SpriteRenderComponent? The 'proper' way would most likely be to have 2 components, a RenderComponent, and a SpriteComponent, and later on you can filter entities where you need the generalized RenderComponent, or the specifics of the SpriteComponent.

This kind of extending for Components is a bit odd in this architecture, but explain your use-case!
(I plan to do something similar with the new Systems API though)

P.

[buckle2000]

Polymorphism. Besides SpriteRenderComponent, we can have ShapeRenderComponent...
Each child class may have different methods, e.g. SpriteRenderComponent has a method to manage its children, while TextFieldComponent has methods to change text in it. Then we only need 1 view that cares about RenderComponent interface to draw them on the screen, while other views/entities can use unique methods if the type of RenderComponent is known.

[PDeveloper]

Still the 'correct' way would be to have:
[RenderComponent, [SpriteComponent, ShapeComponent, TextComponent]]
And in the Rendering system, it picks up each of the combinations to do special stuff.

Another alternative is to create a RenderComponent, which encapsulates a reference to your base class or interface.

Polymorphic ECS isn't something supported well by Eskimo, but I did look into. Will have more thinking time and see if I can adapt some utilities for those kinds of ECS, recent refactors should help with this.

[buckle2000]

And in the Rendering system, it picks up each of the combinations to do special stuff.

I mean rendering system only need to draw IBitmapDrawable, not do special stuff.
Other systems might do special stuff like tweening.

[PDeveloper]

Well yes, then the Rendering System only requests RenderComponent entities, and other systems can request [RenderComponent, SpriteComponent] entities to do the special stuff necessary!

[buckle2000]

So then [RenderComponent, SpriteComponent] need to share Sprite instance.
And what if I have more than one Interface and each Interface has multiple subclass? Then there will be hundreds of combinations and hundreds of systems.

[PDeveloper]

Hmm, I'm getting the feeling that you're wrapping a rendering engine that has it's own display hiearchy?

In which case, you'll have to wrap the actual objects with a component, and somehow match the type manually. I'll have a think if there are any better solutions.

[buckle2000]

Yes, I was using Kha, where you need to draw things manually on screen like in OpenGL.

[buckle2000]

Seems like there is no way to achieve this unless you use http://api.haxe.org/Type.html#getClassFields, which should be slow.