Entity Events. Round 2. #2835
Description
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.