| 123456789101112131415161718192021222324252627282930 |
- * 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
- * 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)
- * runner proposal: https://en.wikipedia.org/wiki/Fork%E2%80%93join_model https://slide-rs.github.io/specs/03_dispatcher.html
- * is it possible to iterate all the components assigned to an entity through a common base class?
- * work stealing job system (see #100)
- * can we do more for shared libraries? who knows... see #144
- * meta: sort of meta view based on meta stuff to iterate entities, void * and meta info objects
- * meta: move-to-head optimization when searching by name on parts (data, func, etc)
- * hashed string: add implicit check on construction for uniqueness (optional)
- * destroy overload that accepts a couple of iterators (see create)
- * allow for built-in parallel each if possible
- * mention hunter in the readme file, section packaging tools
- * travis + windows is now available, try it
- * events on replace, so that one can track updated components? indagate impact
- * tags revenge: if it's possible, reintroduce them but without a link to entities (see #169 for more details)
- * empty components model allows for shared components and prefabs unity-like
- * provide create with a pack of default constructible components to assign
- * allow to replace std:: with custom implementations
- * allow curried function and lambdas on sigh/dispatcher (mixed approach with sinks that accept also delegates?)
- Ready to go:
- * policy based views
- * preferred approach (hints): registry.view<A, B, C>(exclude<D>, policy<A, B>)?
- * previous model used for persistent views as default view, query as old fashioned views
- * is it enough to store a view as <direct set, length>?
|
