| 1234567891011121314151617181920212223 |
- * 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
- * allow to sort groups (::respect can already work with begin/end instead of a whole sparse set)
- -it would ease by far the group trick for hierarchies that requires otherwise more boilerplate
- * events on replace, so that one can track updated components? indagate impact
- - define basic reactive systems (track entities to which component is attached, track entities from which component is removed, and so on)
- - define systems as composable mixins (initializazion, reactive, update, whatever) with flexible auto-detected arguments (registry, views, etc)
- - from Tommaso on discord view<Health, Transform>().where<Health>([](h) {h > 5}).where<Transform>([](t) {t.inside(aabb)});
- * 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
- * add a sort of "fast each" for when users know they are not to add/remove components, it can use directly raw access and improve even further performance
- * 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
|
