|
* long term feature: templated generic vm
|
|
* long term feature: shared_ptr less locator
|
|
* long term feature: shared_ptr less resource cache
|
|
* custom allocators and EnTT allocator-aware in general (long term feature, I don't actually need it at the moment) - see #22
|
|
* debugging tools (#60): the issue online already contains interesting tips on this, look at it
|
|
* runner proposal: https://en.wikipedia.org/wiki/Fork%E2%80%93join_model https://slide-rs.github.io/specs/03_dispatcher.html
|
|
* work stealing job system (see #100)
|
|
* meta: sort of meta view based on meta stuff to iterate entities, void * and meta info objects
|
|
* allow for built-in parallel each if possible
|
|
* allow to replace std:: with custom implementations
|
|
* remove runtime views, welcome reflection and what about snapshot?
|
|
* empty components model allows for shared components and prefabs unity-like
|
|
- each with entity return the shared component multiple times, one per entity that refers to it
|
|
- each components only return actual component, so shared components are returned only once
|
|
* types defined at runtime that refer to the same compile-time type (but to different pools) are possible, the library is almost there
|
|
* add take functionality, eg registry.take(entity, other); where it takes the entity and all its components from registry and move them to other
|
|
* add opaque input iterators to views and groups that return tuples <entity, T &...> (proxy), multi-pass guaranteed
|
|
* add fast lane for raw iterations, extend mt doc to describe allowed add/remove with pre-allocations on fast lanes
|
|
* review 64 bit id: user defined area + dedicated member on the registry to set it
|
|
* early out in views using bitmasks with bloom filter like access based on modulus
|
|
- standard each, use bitmask to speed up the whole thing and avoid accessing the pools to test for the page
|
|
- iterator based each with a couple of iterators passed from outside (use bitmask + has)
|
|
* stable component handle that isn't affected by reallocations
|
|
* multi component registry::remove and some others?
|
|
* reactive systems
|