Ogre Forums

• - an empty entity : 1.7 KB. .......................... for fast query and sparse set
  - an Ogre graphic entity : 5 KB. ..................... encapsulate 1 item
  - (guess) a Bullet entity : 5 KB. ..................... encapsulate 1 rigidBody
  - (guess) an enemy-ship : would use 20 KB. ...... a quite-complex entity : POD + physic + graphic

• UniqueVoidPointer = 24 bytes
  (pointer to its allocator, content address, my allocated address, corruption guard, stack index)
• [#] +50% from use lot of very-low-useful redundants map int<-->entity / int<-->component ID-generator.

• base component = 36 ..................... (a lot of debug-id / flag : useful for debugging)
• blendmode, depthWrite, depthRead, alphaRead, cull, hologramMode, hologramMagnitude
• lightEnable, 7 colors just in case (7*4*4 bytes), textureManipulate (7*4 bytes)
• smokeFlag, billboardType, billboardUp, billboardAngle

• per component = 48 ([#] 8-12 may be enough), used to generate id and fast query

• make component of different entity point each other O(1) without hashing
• work even for 1:N
• cost = 100 bytes per related database ([#] might be 20)

• +70% on top of it from overhead of internally-use allocator inside each system.
  +30% on top of it to make every allocator extendable at runtime.

• global memory = global heap + global stack
• global heap = system 1's heap + system 2's heap + ... + 20's (system_main_entity is one of them)
• system_main_entity 's heap = pool for entity + for component 1 + for component2 + .... + 50's
• (Now, I think I should flatten it.)

hyyou wrote: Entity = 228 ................................... (mainly contain pointer to 50 components)

template <typename C, typename ... Args>
  ComponentHandle<C> assign(Entity::Id id, Args && ... args) {
    assert_valid(id);
    const BaseComponent::Family family = component_family<C>();
    assert(!entity_component_mask_[id.index()].test(family));

    // Placement new into the component pool.
    Pool<C> *pool = accomodate_component<C>();
::new(pool->get(id.index())) C(std::forward<Args>(args) ...);        //"id.index()"  Oh no!

inline void *get(std::size_t n) {
    assert(n < size_);
    return blocks_[n / chunk_size_] + (n % chunk_size_) * element_size_;       //  no!
  
}
.... protected:
  std::vector<char *> blocks_;

• Entityx can avoid allocate the whole block if there are 0 components in a block.
• It is still a lot of waste, except it uses relocation.

• In the final solution, I believe it is (moderately) slower from cache miss if I want something like this :-

  Code: Select all

  Entity pirateShip = ....
  ComponentHandle<Position> pos1=pirateShip;    //access some content
  Array<Entity> pirateTurrets = getAllTurrets(pirateShip);   //using my super fast pointers (aka map)
  for(auto pirateTurret: pirateTurrets ){
      ComponentHandle<Position> pos2 = pirateTurret;
      pos2->pos=pos1->pos + Vec3(1,0,0);       
      //^--- memory must be jump among the whole big array of EVERY entity
  };
  

  In my old ECS, it is a bottle neck. I am not sure whether it will happen again with this design.
  Guessed workarounds 1) iterate from child (turret) instead of parent (ship) ; 2) relocation ;
• User should list all type components for a certain "type" of entity in advance (minor annoying disadvantage)
• hard to add/remove component from an entity (can be workarounded probably with performance penalty)
• Summation of size for every used component of every entity must be < a user-defined number, e.g. 5KB,
  and the 5KB memory will be allocated for every entity. (minor - bad for some rare cases)
• The final design focuses on Component->Entity which is relatively easy and claim that it "could fit in the cache at once".
  However, it simply does not describe how to query a certain type of component from an entity - which is relatively harder.
• (major) Mildly-to-moderate lost data locality if I just want data of 1 type of component. (see an image from http://gameprogrammingpatterns.com/data-locality.html and https://gamedev.stackexchange.com/quest ... ear-memory)

• I like this.
• It suffers the "50 components" syndrome.
• Limit type of component to e.g. 50 (hard-coded).
• The waste memory for 50 components is unavoidable.
• The hard-coded aspect can be solved by using custom memory allocator (or just use below solution).
• The cache miss aspect can be partially reduced by using 1 sparse map for each component type rather than store all of them in entity
  (thank for the idea ).
• (major) Inherently, query Component<->Component of the same entity is significantly slower than the first approach
  e.g. iterate n cache for n components simutaneously in random order.

... So in yours you could maybe have a Smoke Component which is separate to GraphicsComponent, etc ....

- You seem to also be heading down an inheritance design for your components, this is a slippery route and I would advise against it!

• pass to byte buffer e.g. color, hologramMagnitude
• control @property e.g. smokeFlag, hologramFlag