Franco's Edge lib question

[Dinko Pavicic]

Hi all,

I'm looking at Franco's Edge library for entity systems and I can say that I'm quite impressed with it. It's light and simple ( in a positive way ) but yet powerful.

One thing that bothers me with Edge and entity systems overall is how to approach to parent/child relations regarding the transformations and rendering for example.

Ok, for the parent/child I could always put the reference variable to parent Transform component ( which is clunky ) but that doesn't help if entity ordering in the update loop(system) is not right ( parent before child; so I could update parent's transform first and then of the child. ).

There are suggestions on the web that system's entity list should be maintained in a way so the childs are always next to the parent in the list.

For example if we have:

A - entity

B - entity

C - child of A

D - child of A

That list should be ordered:

ACDB

That could be ok approach to the problem ( maybe cumbersome to maintain ) but I cannot see where in the Edge I could force the Entity ordering within the systems. Is that possible or planned maybe?

Same problem is with render order if entities ( or renderable components, to be more in the vocabulary ). For example I would like to use TileLayer library ( https://github.com/matthewswallace/openfl-tilelayer ), which renders sprites in layer batches for the speed sake.

Any suggestions what could be right approach for correct layer render ordering and sprites within them?

I really like the entity system approach but it seems that with great flexibility it creates also problems as described which are foundation of any rendering engine ( the order of things ).

Any help and suggestions really appreciated!

Thanks in advance

Dinko

 

[Franco Ponticelli]

Hi Dinko, thank you for spending the time on edge :)

You are right, Views are not guaranteed to return entities in any specific order. Internally in fact they use a map that does not even preserve the insertion order on some platforms.

That said it is very possible to review that code and to have subclasses of View that can ensure a given sort function. Would that be enough for your use case? Is writing such sorting function easy as well?

If you want to present a use case (with the definition of components the way you want them and possibly systems), we can work together to overcome the limitations of edge.

About the second issue I am not totally sure I understand, edge already provides ways to batch operations and you can have a renderer system for each of your layers. The renderers would extend a base class with small changes in identifying their components. If you have hundreds of layers of course this is probably not the right solution.

Franco

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

[Dinko Pavicic]

Hey Franco,

thanks for quick reply!

I saw that Edge handles nearly all collections via maps which basically nullifies ordering of items by default.

It would be great to have some kind of mechanics to order the components in the systems by some rules ( sorting by z-index for example ) and to be manipulate positions in the list ( be able to simulate some kind of hierarchy between components as mentioned in ACDB example ).

Not sure myself what would be bulletproof approach for this problem of mine ( regarding parent/child transforms ) but as I said ability to manipulate the order of components in the lists would surely open possibilities to do creative stuff with them.

When ordering would be available I was thinking about this ( theoretically, I don't know internal workings of the systems since they are build entirely from the macros thus their code is not easy to comprehend by looking at the github :)

- In the system, I would override 'updateAdded' function. Don't know for sure if this is a callback when entity is added in the system. Correct me if I'm wrong.

- In the overrided updateAdded I can then set the correct index or whatever to put the added entity to desired position in the list( if they are implemented with arrays for a simple example here ). Or sort the list or whatever I want.

Voila!

Maybe it would be great to control the overall update in the system not per entity as shown in github example. Is that possible by overriding the _process_ function?

That way I could write system:

- with additional, let's say linked list of entities where I could control the entity ordering.

- make a loop through all entites in overriden _process  function but using my ( ordered ) list

- override 'updateAdded' and put entiities in my linked list orderer as it suits me

- overrid 'updateRemoved' to do clean-up stuff in the custom list

I was investigating a bit what people are doing in artemis,ash and similar are doing and it seems that they are doing exactly the same:

https://code.google.com/p/spaceship-warrior/source/browse/src/com/gamadu/spaceshipwarrior/systems/SpriteRenderSystem.java

http://stackoverflow.com/questions/23222053/data-structure-for-tile-map-for-use-with-artemis

Check out for 'protected void inserted(Entity e)'

Personally I would no't like for Edge systems to be too 'smart' and do the sortings and stuff out of the box but to provide certain hooks for overriding and bending them to programmer's needs.

Regarding the rendering I was pointing to ordering of layers and ordering of sprites in the layers. That's also related to the order manipulation and sorting ( which layer/sprite comes above, which below; if doing 2D stuff ).

As you mentioned, layers could be done as separate systems but sprite components would be always drawn in the order they are created as there is no way to alter their list indexes afterwards ( maps ).

Thanks again Franco for the help!

Dinko

[Franco Ponticelli]

I am intrigued to add those kind of hooks in edge and I think it is very possible. In the meanwhile I also think that the problem can be worked around. Every view has `xAdded`/`xRemoved` method overrides. Also there is a `before` override that occurs only once before the cycle of `update`s. If all of that falls short you can implement and `update` function that takes no argument. In this case it will be invoked only once per update cycle (not once for each entity since it is not related to any specific entity). That in conjunction with views allow to process batches of entities. If you define a field `monsters : View<...>` it will be automatically populated and you can iterate on it during `update`. You still have the opportunity to use `monstersAdded`/`monstersRemoved` that you could use to build your linked list.

Franco