entt: Organizer always returning a simple linear graph

I have three functions:

void processMessagesStatic(entt::view<entt::get_t<universe>>);
void queryGalaxies(entt::view<entt::get_t<const star>>, entt::view<entt::get_t<galaxy>>);
void updateCelestialOrbits(const entt::registry&, entt::view<entt::get_t<const orbit, position, const child_of>>);

registered with:

	organizer.emplace<&processMessagesStatic, galaxy>("processMessages");
	organizer.emplace<&queryGalaxies>("queryGalaxies");
	organizer.emplace<&updateCelestialOrbits, const pixiel::mass, const pixiel::tick>("updateCelestialOrbits");

And I get this graph: I expected to have the node [0] with nodes [1] and [2] as reachable (so they run in parallel)

I have even tried to change the signature of queryGalaxies to: void queryGalaxies(); And the result was still the same linear execution graph. (here I’d expect to have two root nodes with that empty signature). Am I doing anything wrong, or maybe I’m missing something?

Thank you for the library!

About this issue

Original URL
State: closed
Created a year ago
Comments: 18 (10 by maintainers)

Most upvoted comments

All makes sense now! Tested and looks beuatiful!

Thank you both for your time and patience!

RicardRC on Mar 21, 2023

I was wrong actually. I simply didn’t remember an undocumented feature that seems to have been implemented on purpose. The culprit is this line within the organizer.hpp file:

builder.set(type_hash<Registry>::value(), requires_registry || (sizeof...(RO) + sizeof...(RW) == 0u));

The second parameter is also known as is_rw. An empty function, that is, a function that doesn’t have dependencies is considered a sync point. I think the basic idea is: if you don’t want anything, it means you already have everything but I can’t know what that everything is. So, when in doubt, it’s considered a sync point. That is the safest approach actually.

skypjack on Mar 21, 2023

Maybe the fact that asking for the registry counts as asking for everything should be added in the docs somewhere?

Fair enough. I was almost sure there was actually. 🤔

Do you know of a way of accessing named components this way?

Green-Sky is right. I’m slowly introducing support to named components all around. If you look at the commits on the wip branch, I’m decoupling groups from the registry now in order to also support multiple storage of the same type (that is what named components offer after all). So, yeah, it’s just a matter of time and it will also reach the organizer. 🙂

This still does not work as I expect.

How do you register them? I don’t see the code.

skypjack on Mar 20, 2023

don’t worry, I’m used to that <.<

Not ok! And I’m really sorry about contributing to that feeling.

Yes, just put them into the system’s function signature. Example where I used it

You just put the component type there and that’s it? It’s magic! Thank you! I guess it’s actually not as magical as the same happening with views, but it never crossed my mind to try. Do you know of a way of accessing named components this way? I’ll probably just end up using a single one per component type, but I lose nothing by asking!

RicardRC on Mar 19, 2023