Multiple layers per entity about flashpunk

[IkonOne]

Moving the layer property to Graphic is in my opinion a nice solution. This allows each graphic to render to an individual layer which would do wonders for top down perspectives among other neat tricks. However, just doing that is not backwards compatible.

To accomodate that minor inconvenience, and also add some additional functionality, the layer field of the entity could be changed to a property and a bool be added to the entity such as 'forceLayers'. This way, if forceLayers is true, the Entity sets the layers of its graphics to the same layer that the entity is, maintaining the same functionality that is in the current version of FlashPunk. And you can still hack in rendering code the the entity if needed.

But this poses a problem as well because the child graphics are now forced to change their layer. Being able to switch a graphics back and forth between its parent entities layer and its layer may also be needed. This could be addressed with an ILayerable/IRenderable interface that is implemented by Entities and Graphics, and also would clean up rendering code as there wouldn't have to be checks to see if some renderable Item is a Graphic or an Entity.

Another added benefit to the Interface approach would be that GraphicLists could also force layers for its children, or not.

My two cents. Hopefully I was clear...

[Draknek]

But this poses a problem as well because the child graphics are now forced to change their layer. Being able to switch a graphics back and forth between its parent entities layer and its layer may also be needed.

Can you restate this? I don't think I follow you here.

This could be addressed with an ILayerable/IRenderable interface that is implemented by Entities and Graphics, and also would clean up rendering code as there wouldn't have to be checks to see if some renderable Item is a Graphic or an Entity.

When would there be ambiguity whether a renderable thing is a Graphic or an Entity?

[IkonOne]

The ambiguity I am referring to is in the render function of world which currently loops through a linked list of entities, but could loops through a LL of IRenderable.

But this poses a problem as well because the child graphics are now forced to change their layer. Being able to switch a >>graphics back and forth between its parent entities layer and its layer may also be needed.

Can you restate this? I don't think I follow you here.

Yeah that was a bad explanation...

The problem I am talking about would be that each Graphic has it's own layer Field. When its parent entity changes that field, that field cannot be reverted to its previous value unless its previous value was stored before it was changed by the parent entity.

And since I am revisiting this, an minimal example interface:

public interface IRenderable 
{
    function get forceLayer():Boolean;
    function set forceLayer():void;

    function get layer():Boolean;
    function set layer():void;

    function get next():IRenderable;
    function set next():void;

    function get prev():IRenderable;
    function set prev():void;

    function render(target:BitmapData, ...):void;
}

Having this interface opens the option to render objects whose class is something other than those that have a render function currently in Flashpunk.

EDIT: But interfaces are also counter to the current standards within Flashpunk.

[Draknek]

Idea (which I don't think I necessarily like): Have graphic.layer be relative to the containing Entity's layer.

So entities are rendered at entity.layer, and graphics are rendered at graphic.layer + graphic.entity.layer

This way, you don't need an extra boolean property lying around, and legacy code works because graphic.layer = 0 by default...

(Possibly you'd want to call it graphic.layerModifier or something better, to make it more obvious that it's always relative).

Also: the reason renderPrev/renderNext exists is actually a performance optimisation that would be negated by having them accessed by a getter/setter.

I'm not 100% opposed to interfaces: if the user never sees them then it doesn't matter so much if it matches the current standards.

[IkonOne]

I didn't think about the performance hit from the getter/setter. The interface was simply a suggestion to impose a standard. I don't necessarily think one is needed.

What if graphic.layer defaulted to -1 and graphics are rendered at:

graphic.layer == -1 ? graphic.entity.layer : graphic.layer;

That gets rid of the boolean and is a 'little' more intuitive than the graphic.layer being relative the it's entity. I'm kind of on the fence with this though because I can't think of anywhere in FP there is a default behavior if a value is outside of it's regular bounds.

Hmm. I'll think on it some more.

[Draknek]

Definitely nope to -1: that's a perfectly valid layer value. If we had to use a magic constant it should be ridiculously large, but I'm uneasy about that still.

[IkonOne]

I'd rather use a bool than a magic number tbh. And I can't really think of any good way to get around having a bool other than your suggestion that a graphic render relative to its parent entity. But even that could be problematic because what happens when an entity changes its layer? How is the graphic informed so it can change to the proper layer? Maybe: graphic.updateLayer();

[Draknek]

Entities always know which graphics are attached to them, so I don't see that as a problem.

[IkonOne]

I'm leaning away the graphic.layer being relative to its entity. It is an elegant solution codewise, but it is not particularly intuitive in use. It is inconsistent with common practices. Most people are going to be accustomed to layers being on a global context, not its parents context.

Why not just add the bool property instead of the function? Or maybe both even. It's not like it is creating a significant amount of bloat, especially considering the functionality that is gained.

[Draknek]

Observation: if we're adding a boolean property that will need explaining, we could have it be Graphic.layerIsRelative (or something more snappily named). That would basically combine the two options.

Why not just add the bool property instead of the function?

Instead of what function?

[IkonOne]

Instead of what function?

Graphic.updateLayer();

But in light of your observation, I am retracting that. I think that that right there would be perfect. It maintains the default functionality while offering two alternative, more capable methods of layering.