0

In Artemis' Systems you specify what Components are required by the System, i.e. if and Entity at some point has at least all the required components it is considered that it is added to the System, i.e. next frame the System will process it. But in Artemis you also get callback functions such as added or removed that tell that a new Entity is added to a System.

In EntityX, on the other hand, I see that Systems don't require specific components. The entities are requested on the fly, and there is not concept such as Entity added to a system. Hence, I want to understand how I can do the following. I need in System ABC that processes all entities that have A, B and C get some event when there was an Entity with components Aand B and I have also added component C. How to recognise and handle that situation.

Narek
  • 38,779
  • 79
  • 233
  • 389

1 Answers1

0

In EntityX there is no such concept as Entity belongs to a system or to systems. In each system you can just get a list of Entities that have particular Components by using entities_with_components method which each time queries the entities and, hence, slower that if for each System there would be the current active entity list.

Narek
  • 38,779
  • 79
  • 233
  • 389
  • Your statement about performance is not correct, due to cache coherence. If each System holds a list of pointers to components it is interested in, the underlying component data may be accessed in any order, destroying cache coherence. In theory EntityX can avoid this because it iterates over components in order, though the current storage backend is not optimal for cache utilisation. – Alec Thomas Apr 16 '15 at 01:31
  • @AlecThomas `entities_with_components` returns entities with such an order that cache coherence is preserved, right? Why shouldn't we able store the pointers of those entities in that order for a system and reconsider the list, once a new entity is added? – Narek Apr 16 '15 at 06:02
  • Because maintaining order is expensive and it would need to occur for every component that every system was interested in. Imagine if you had 10 systems, each interested in ~5 components each. That would mean you were maintaining ordering for 50 separate lists of pointers. Additionally there's the question of what data structure to use. std::list has unacceptable performance, std::vector is fast to iterate and append but not fast to maintain order, and std::map is typically going to have bad cache performance. – Alec Thomas Apr 16 '15 at 07:07
  • (actually there would probably just be an immutable list per component, though the count would be the total number of component types instead...so 50 types of components, 50 ordered lists) – Alec Thomas Apr 16 '15 at 07:52
  • @AlecThomas What about some benchmarking? Cache friendly vs static list without querying on each update? – Narek Apr 16 '15 at 08:09