Display order

[markknol]

Hi there,

I am writing this because I have a similar project, an ECS based on Flambe for my games (because Flambe indeed is nice and pragmatic 👍 ). I have a version for Pixi.js and Heaps. (btw its not opensource/online so cannot really show something)

I was wondering how this framework deals with display order.

What I did is maybe less generic as what you did, but I'm curious how you deal with the display list.

• Keep most of Flambe which isn't specific for platform the same. Replace flambe's systems (stage/keyboard/etc..) with specialized systems for the platforms. It's not that nicely generic as you have (it more looks like wrecked Flambe 😋 ), but is still usable.
• I've created a DisplayComponent. This replaces Sprite and friends. A DisplayComponent holds a container, which is native pixi/heaps Sprite. In onStart of DisplayComponent, I look in parents for DisplayComponent, and attach the container to the parent container. The root DisplayComponent is added to the stage. Doing this makes it automatically work.

The problems I deal with is;

• If a new DisplayComponent is added to the parent tree after a DisplayComponent is attached to the displaylist, it's hard to put this new container in-between (or even know that this event happened without making it lookup everything every frame).
• If an Entity is reparented (for example I put in same parent Entity to sort it/put it on top), its hard to keep the order of the displaylist the same as the Entity tree. I cannot use onAdded/onRemoved because its not guaranteed that it has full access parent Entity tree yet. I now have to call reparent() manually but this is not that nice.

I see that you have a similar DisplayComponent how it is attached to display list seems to be done differently.
How does GASM deal with native display list v.s. Entity tree and how responsive is it when reparenting happens?

[lbergman]

Hi Mark!

Currently I'm mostly focused on the OpenFL backend, since I still need canvas fallback, and what I have done in my SpriteComponent so far is to simply get the parent entities SpriteComponent, get the sprite for that component and add the sprite for the current component to that. So that way the display follows the entity graph, and siblings are depth sorted in the order they are added. However, there is no implementation yet for sorting depth in the graph, but it is something I considered if it is possible handle in a generic way as part of GASM, but it has not been a priority yet.

For example you have Entity A containing a DisplayComponent which contains entities B, C, D also containing DisplayComponents. Adding them in that order means that D is on top and A at the bottom. If you now want to bring B on top of D it should not be hard to hook in a way to swap to sibling sprites in a non-generic way. So if I needed a quick solution I would probably just have an extended DisplayComponent which accesses for example OpenFL sprite.swapDepths in response to a model change.

If you want to move Entity D to the parent of Entity A and have the display list follow, it is not something I have given any thought to yet. If I need to manage depth I usually try to keep that contained to siblings, and typically have a quite static graph. So currently you can add or dispose a component, and that is it. However, as long as you make sure you keep state in a separate model component, I guess removing and adding could work unless you have a component that is heavy to instantiate?
Can you give an example of a scenario where you need to move components in the graph?