You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Even though today we are closer to specs, we still have some fondamental differences. With the traditional design we had issues to integrate some features (like Box2D) that were not planned to be used in a multithreaded environment, so we introduced the concept of modules that are independant parts which provide and own their components.
Also we have the concept of Accessors that statically ensures to the user and the library that the entity is alive and the reference valid.
Allowing us to avoid some checks most of the time.
We have Groups that are like Aspects that represents a set of entity that Systems can iterate on instead of calculating it each processing steps although it introduces its own caveat.
Our System Scheduler is based on what systems need to read and write instead of associating a priority to each system, but I suppose we could implement this on top of specs.
At last, we had a lot of trouble to handle serialization and our new ecs is (in theory) designed to ease that.
In order to use specs in lazybox we would currently either need some changes in specs that might not be in the scope of this library or at least find new alternatives on our side.
The text was updated successfully, but these errors were encountered:
@kvark I'm not sure what exactly this issue is useful for. Are there any points we should address or is it a just comparison?
Also we have the concept of Accessors that statically ensures to the user and the library that the entity is alive and the reference valid.
We don't have that, but I'm not sure about the limitations it brings
We have Groups that are like Aspects that represents a set of entity that Systems can iterate on instead of calculating it each processing steps although it introduces its own caveat.
Seems like we have that
Our System Scheduler is based on what systems need to read and write instead of associating a priority to each system, but I suppose we could implement this on top of specs.
Highly flexible on our side:
dependencies
aspects
barriers
or manual RunNow / user-built scheduler
At last, we had a lot of trouble to handle serialization and our new ecs is (in theory) designed to ease that.
95: Add functions for determining the maximum useful thread count r=Xaeroxe a=Xaeroxe
This could be useful for reducing CPU overhead in Amethyst
Co-authored-by: Jacob Kiesel <kieseljake@gmail.com>
@Liotitch wrote:
The text was updated successfully, but these errors were encountered: