Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Entity Events. Round 2. #2835

Closed
tower120 opened this issue Sep 17, 2021 · 2 comments
Closed

Entity Events. Round 2. #2835

tower120 opened this issue Sep 17, 2021 · 2 comments
Labels
A-ECS Entities, components, systems, and events C-Feature A new feature, making something new possible S-Needs-Design-Doc This issue or PR is particularly complex, and needs an approved design doc before it can be merged

Comments

@tower120
Copy link

In #2070 was proposed following mechanism:

  • Each Entity have opt-in/opt-out EventComponent
  • EventComponent added when events pushed to entity. EventComponent removed when events consumed by all systems/readers.

While working on Small Buffer Optimized version of https://github.com/tower120/rc_event_queue / bevyengine/rfcs#32 for experimental implementation of this, I found following:

  • If SystemA read all events from Event, and SystemB not, we still can not remove EventComponent safely, because it contains unread events. Under this circumstances, on each run, SystemA will still access EventComponent to found that it is empty.
  • In order to add/remove EventComponent we either should have excessive memory moves, using Sequential ECS Storage; either we use Spatial Storage and lose benefits of linear memory access. Since this is event system I assume that Spatial Storage usage is the only way.
  • In the end... Spatial Storage access is not that different from Component access by EntityId.

So... I come to the idea, that if we will fetch components from Sequential Storage by EntityId, in the order they lay in storage - we still should benefit from linear memory access.

The idea is - to have EventQueue<(EntityId, EventMessage)> attached to each archetype_storage/table, and have EventQueue queue "sorted" by Entity index in correspondent archetype storage. So, in the end, readers will read storage as linear as possible. More over, systems that emit event messages, will most certainly, do this in the order they iterate storage - hence emitted messages should already be mostly sorted(!).

In order to reduce overhead from "sorting", we could temporary store Vec<(EntityId, EventMessage)> for each event writing system. Sort each of them (they probably will be in sorted state already), and then, at some point (end of the stage?), push messages from vecs in a sorted way (pop_front vec with min first entity index) into EventQueue.

@tower120 tower120 added C-Feature A new feature, making something new possible S-Needs-Triage This issue needs to be labelled labels Sep 17, 2021
@tower120
Copy link
Author

tower120 commented Sep 17, 2021

All this sorting thing have sense, only if we consider that user will try access components from the SAME entity as EventMessage. As far as I can guess - that was intention in initial proposal.

@NiklasEi NiklasEi added A-ECS Entities, components, systems, and events and removed S-Needs-Triage This issue needs to be labelled labels Oct 4, 2021
@alice-i-cecile alice-i-cecile added S-Needs-Design This issue requires design work to think about how it would best be accomplished S-Needs-Design-Doc This issue or PR is particularly complex, and needs an approved design doc before it can be merged and removed S-Needs-Design This issue requires design work to think about how it would best be accomplished labels Dec 12, 2021
@alice-i-cecile
Copy link
Member

Closing as a duplicate of #1626.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ECS Entities, components, systems, and events C-Feature A new feature, making something new possible S-Needs-Design-Doc This issue or PR is particularly complex, and needs an approved design doc before it can be merged
Projects
None yet
Development

No branches or pull requests

3 participants