| 12345678910111213141516171819202122232425262728293031323334353637383940 |
- * 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)
- - 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
- * allow for built-in parallel each if possible
- * allow to replace std:: with custom implementations
- * remove runtime views, welcome reflection and what about snapshot?
- * 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
- * add fast lane for raw iterations, extend mt doc to describe allowed add/remove with pre-allocations on fast lanes
- * registry.each<T...>(first, last) by iterators, entities/components guaranteed
- * built-in support for dual (or N-) buffering
- * allow for custom stomp functions
- * deprecate/replace snapshot
- * hibitset, views and non-owning groups
- * custom (decoupled) pools ==> double buffering, shared components, multi-model
- * 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
- * multi component registry::remove and some others?
- - auto foo(It first, It last = entity_type{null})
- * range based registry::remove and some others?
- * add examples (and credits) from @alanjfs :)
- * explore the possibility to wrap other backend with a XHandler component
- * use [[nodiscard]] consistently for safety purposes
- * static reflection, hint: template<> meta_type_t<Type>: meta_descriptor<name, func..., props..., etc...>
- * null support for entt::component
- * add ENTT_CUSTOM_NAMED_TYPE for custom names
- * Make another attempt to overcome named types
- * meta: members+class as fake functions, is it possible?
- * named types: almost-stable index optimization for direct access to pools, no more linear searches
|
