Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The case for Lazybox ECS #95

Closed
kvark opened this issue Feb 5, 2017 · 2 comments
Closed

The case for Lazybox ECS #95

kvark opened this issue Feb 5, 2017 · 2 comments

Comments

@kvark
Copy link
Member

kvark commented Feb 5, 2017

@Liotitch wrote:

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.

@torkleyy
Copy link
Member

torkleyy commented Jun 9, 2017

@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.

Serialization could be easier.

@torkleyy
Copy link
Member

Moved to wiki.

xMAC94x pushed a commit to xMAC94x/specs that referenced this issue Mar 10, 2021
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants