From 01d8f2c7e6ffb760d36ce21706e9a1cc6bda9fdf Mon Sep 17 00:00:00 2001 From: Michele Caini Date: Tue, 12 Mar 2019 23:23:25 +0100 Subject: [PATCH] updated TODO --- TODO | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/TODO b/TODO index 8c88c475b..2c07fdde3 100644 --- a/TODO +++ b/TODO @@ -6,18 +6,14 @@ * 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 -* hashed string: add implicit check on construction for uniqueness (optional) * allow for built-in parallel each if possible * 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 * allow to replace std:: with custom implementations -* cleanup - see https://github.com/skypjack/entt/commit/ad5cedc08c83e8cbcc8aaeac9634d44624ffe35a#commitcomment-32380903 * 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 -* allow some features by component type (eg registry.assign(entity, component); - - it could be possible for eg default constructible types by storing aside (pool data) erased functions - - does it worth it? * 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().where([](h) {h > 5}).where([](t) {t.inside(aabb)}); +* remove runtime views, welcome reflection and what about snapshot?