also fixes a test that breaks with wasm (ComponentHolderById). Looks like in the WASM tests the id of the component was 2 instead of 0. Using the component's real ID is anyway cleaner.
This PR was created to simplify a certain problem that I faced in QuillyJumper for the render system. I needed to iterate over an index of entities of a family in the render system (background entities, normal entities and foreground entities).
Between those entity render calls I also had the tiledmap render calls. I solved it by simply introducing entity tags and tag background and foreground entities with a bgd and fgd tag. The RenderSystem then had three separate families for foreground, normal and background entities.
While that worked, I did not like it a lot.
Giving a family the possibility to iterate from index A to index B might also not be that useful and maybe even tricky to implement (not sure).
That's why I came up with the idea to use the partition function of Kotlin (which actually could also be solved by using filter calls e.g.).
The new solution to my RenderSystem now is to have just one family of entities, sort them at the beginning of the system's onTick function (=normal behavior = good :) ) and then split that family into three parts (=partition):
entities with z-index < 0 (background)
entities with z-index = 0
entities with z-index > 0 (foreground)
I will use the new partitionTo function for that to avoid creating new collections each frame.
In my scenario this should simplify the RenderSystem and also make it faster because I just have one family and one sort call instead of three families with three separate sort calls.
also fixes a test that breaks with wasm (ComponentHolderById). Looks like in the WASM tests the id of the component was 2 instead of 0. Using the component's real ID is anyway cleaner.
This PR was created to simplify a certain problem that I faced in QuillyJumper for the render system. I needed to iterate over an index of entities of a family in the render system (background entities, normal entities and foreground entities).
Between those entity render calls I also had the tiledmap render calls. I solved it by simply introducing entity tags and tag background and foreground entities with a bgd and fgd tag. The RenderSystem then had three separate families for foreground, normal and background entities.
While that worked, I did not like it a lot. Giving a family the possibility to iterate from index A to index B might also not be that useful and maybe even tricky to implement (not sure).
That's why I came up with the idea to use the partition function of Kotlin (which actually could also be solved by using filter calls e.g.). The new solution to my RenderSystem now is to have just one family of entities, sort them at the beginning of the system's onTick function (=normal behavior = good :) ) and then split that family into three parts (=partition):
I will use the new
partitionTofunction for that to avoid creating new collections each frame.In my scenario this should simplify the RenderSystem and also make it faster because I just have one family and one sort call instead of three families with three separate sort calls.