| 1234567891011121314151617181920212223242526272829303132333435363738394041 |
- * 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
- * work stealing job system (see #100)
- - mt scheduler based on const awareness for types
- * meta: sort of meta view based on meta stuff to iterate entities, void * and meta info objects
- - remove runtime views, welcome reflection and what about snapshot?
- * allow for built-in parallel each if possible
- * allow to replace std:: with custom implementations
- * types defined at runtime that refer to the same compile-time type (but to different pools) are possible, the library is almost there
- * add opaque input iterators to views and groups that return tuples <entity, T &...> (proxy), multi-pass guaranteed
- * allow for custom stomp functions
- * custom (decoupled) pools ==> N-buffering, shared components, multi-model, hibitsets, and so on
- - explore the possibility to wrap other backend with a XHandler component
- * snapshot rework/deprecation
- - create(hint: entity) -> force-create
- - assign<T...>(first, last)
- * use unordered_map for named pools and context variables:
- - use direct access (pool-like) also for context variables
- - allow for key/value variables where the key is an ENTT_ID_TYPE
- - improves multi-stomp
- * add examples (and credits) from @alanjfs :)
- * static reflection, hint: template<> meta_type_t<Type>: meta_descriptor<name, func..., props..., etc...>
- * ENTT_NAMED_TYPE -> ENTT_EXPORT and add also ENTT_EXPORT_WITH_NAME
- * meta: members+class as fake functions, is it possible?
- * meta: export implicitly generated named types if possible
- * welcome -ftime-trace to inspect compilation time
- * add meta support to registry:
- - entity for each component
- - opaque get
- - and so on (I'm lazy) :)
- * registry::each to iterate all components of an entity
- * named types: almost-stable index optimization for direct access to pools, no more linear searches
- - can implicitly generate types for meta benefit from a similar approach?
- * detect family on a macro based model
- * is it possible to make named type constraints namespace-free?
- * stomp -> merge (naming is hard as heck, it's known thing)
- * observer: user defined filters (eg .replace<T, &function> or .group<T, U, &func>)
- * use meta_handle for inputs to invoke/ctor/...
|
