Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 22 Jan 2011
Offline Last Active Jul 21 2015 02:30 PM

Posts I've Made

In Topic: Dealing with different collision responses in an entity-component system

26 June 2015 - 12:09 AM


I use a method which is similar to tiago's but is extremely simplified. I use Bullet physics as my collision detection system, artemis-cpp for the ECS architecture.


  1. Bullet has a function performDiscreteCollisionDetection() (or stepSimulation() if you want dynamics as well). After calling this, all overlapping pairs (ie colliding objects) will be available in an array that bullet maintains internally.
  2. Loop over this array (note: it's an array of btCollisionObjects so use the userPointer field to get the entity) and add a collided component to the entities in each pair
  3. The collided component in one entity stores the id of the other entity.

Here is the system logic

  • All entities having the collided component as well as a health component will have their health reduced by the amount in the other entity's damage component
  • All entities having the collided component as well as a Damage component will just destroy themselves

For your case, you can store additional info in the collided component, and use that to update the transforms of your entities so they no longer collide.

Ofcourse this might be a poor method to do this, but hopefully you can see how a collision detection system can cooperate with entities and systems.

In Topic: Slow down: Artemis C++ Port & SDL 2

17 April 2015 - 01:49 AM



I'm using artemis-cpp as well. In my case, if the number of entities passes a certain threshold the app starts slowing down. This is on a 4th gen i5 with gtx 860m. I suspect its due to the fact this implementation does not have a proper struct of array approach. Check the addcomponent function in entitymanager.cpp file, in that you can clearly see they use a Bag<component *>. A bag itself defines its array like E *data, where E can be any type. Effectively, you get

Bag<component *> components;
 // which, inside entitymanager, translates to
component **data;

See? Its an array of pointers (EDIT: Its not a technically an array of pointers but a pointer to a pointer. I said array because later its allocated and used as a normal array). Now I may be completely off here but it looks to me that this causes the code to jump around when accessing these pointers, which is what the AoS approach aims to solve. I'm at work so can't try it, but IMO using an array of plain data instead of array of pointers might help.


EDIT2: A bit offtopic, but you can get rid of that if statement by using a delayedEntityProcessingSystem to get rid of branches

In Topic: How should systems pick which entities to process? (Entity Component Systems)

07 April 2015 - 05:04 AM

You could take a look at artemis (C++ port) https://github.com/vinova/Artemis-Cpp .

What they do is similar to how phil_t described it earlier.


  • Each entity has an id, a type bitstring and a system bitstring.
  • Everytime you add a component to an entity, its type string is updated, but not the system string. Also, that entity is added to a "refreshed" array
  • At the start of your main loop, you need to call a loopstart() function ( world.loopStart() ). This function iterates over all the entities in the refreshed array
    • In loopstart, each entity that was refreshed will be acted upon by all the systems registered with the world object
    • For each system, the system's bits will be compared with the entity's type bits ( the system's bit indicates what all components/types will this system act upon)
    • EDIT: The previous point is a bit incorrect. The systems themselves will have a system bit and type bits. The system bit will identify that particular system, while the type bits will identify what all components are required if an entity wants to be acted upon by that system
    • If the entity is interested in that system(i.e. the corresponding type bit(s) is/are set), then its system bitstring will be updated, and that entity will be added to that system's actives list
  • When you call any system's update() method, it will only iterate over the entities in its actives list.
  • The only downside I see here is that your changes to an entity will not be available in the same loop. This is actually a good thing, as explained here

In Topic: Basic enemy design

07 April 2015 - 04:41 AM

How about this ?

In Topic: Entity,Components: Issue in immediate refresh

18 March 2015 - 10:21 AM

Thanks for the reply!


Obviously the easiest way to deal with that problem is to defer all changes. Unfortunately I'm not familiar enough with Artemis to know what can be done. My attempts would be to have both immediate and deferred handling. If the framework does not provide it (and it is fine to use otherwise), then patching it may be an option!?



Actually, this is how artemis deals with entity changes by default. You add a component, then call refresh on that entity. Refresh() will just add that entity to an array. At the beginning of the next frame, you just need to call loopstart() which will take the refreshed array from the previous frame and update all the entities in it.


The reason why I asked about immediate updates is that the order in which I call my updates and handle the data in the systems was giving me trouble with deferred updating. I think I'll try to rectify that problem now instead of hacking my way around deferred updating.