You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This makes me wonder about few more general architectural questions regarding dispatcher and registry:
a) Is entt::dispatcher a good fit for these kind of events?
These events originate outside the ECS, but multiple systems need to react (renderer surface resize, UI layout, shutdown logic, etc.). Using dispatcher feels natural here, but I’m not sure whether this aligns with EnTT’s intended patterns or if there’s a more idiomatic approach.
b) Is it ok for dispatcher handlers to mutate the registry?
For a WindowCloseEvent, I want to destroy the window entity. If I do this in a listener, it means the handler needs access to the registry. The cleanest way I found is storing a handler object in registry.ctx() and connecting a member function. However, this makes a context variable stored inside the registry able to reach back up to the registry, which feels awkward.
c) Is it ok for dispatcher events to be enqueued/triggered in a system and dispatcher.update() to be called inside a system?
d) Would a tag-component approach be more idiomatic?
For example, adding a WindowClosed component and having a system process and remove it.
e) Are entt::observers actually a solution for this kind of problem?
Context:
currently single-threaded,
main world and render world are separate registries,
render world extracts from main each frame (inspired by Bevy).
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi, I’m building a small engine (for my master’s thesis) using EnTT.
I intentionally model windows as entities in a “main world” registry (inspired by Bevy’s approach).
Currently, I translate platform events (GLFW) into EnTT dispatcher events, for example:
This makes me wonder about few more general architectural questions regarding dispatcher and registry:
a) Is entt::dispatcher a good fit for these kind of events?
These events originate outside the ECS, but multiple systems need to react (renderer surface resize, UI layout, shutdown logic, etc.). Using dispatcher feels natural here, but I’m not sure whether this aligns with EnTT’s intended patterns or if there’s a more idiomatic approach.
b) Is it ok for dispatcher handlers to mutate the registry?
For a WindowCloseEvent, I want to destroy the window entity. If I do this in a listener, it means the handler needs access to the registry. The cleanest way I found is storing a handler object in registry.ctx() and connecting a member function. However, this makes a context variable stored inside the registry able to reach back up to the registry, which feels awkward.
c) Is it ok for dispatcher events to be enqueued/triggered in a system and dispatcher.update() to be called inside a system?
d) Would a tag-component approach be more idiomatic?
For example, adding a WindowClosed component and having a system process and remove it.
e) Are entt::observers actually a solution for this kind of problem?
Context:
For reference, this is my current demo:
Details
Any guidance would be appreciated.
Beta Was this translation helpful? Give feedback.
All reactions