sadpmpk
/
HATPC
1
0
Fork 0
Code Issues 11 Pull Requests Projects 4 Releases Wiki Activity

Update 'Step 0: ECS Architecture'

master
sadpmpk 2022-12-30 04:31:42 -05:00
parent 0a3198317c
commit 46cf360c26
1 changed files with 4 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
Step-0%3A-ECS-Architecture.md

@ -57,10 +57,11 @@ Due to the implementation of the data structure, it can only handle void pointer
The `to_add` and `to_remove` fields are to handle _iterator invalidation_. This is explained in the lecture series. This arises when the data structure is modified _while_ iterating through it. When adding or removing an entity, they are not immediately added to the map but is added to the respective fields. After that, the entity manager will be updated to properly include the newly added entity and drop the removed entity. Due to this design, this update procedure has to be explicitly called.
# Memory Pool
In a game, it is expected than entities can be created and removed at any time, thus it makes sense to use dynamic allocation for them (using malloc/free). However, it does have performance drawback. Particularly, I am not too fond of the slower call speed and memory fragmentation that can happen due to this.
One way to solve this is to implement a memory pool for the entities and components. This way, a new entity will merely draw from the pool, and a removed entity will just return to the pool. No new allocation needed. This is covered by the lecture series as well, though it is much later down the series.
This is actually a premature optimisation, which is bad. However, I thought it would be fun to implement a memory pool. That's why I did it.
In a game, it is expected than entities can be created and removed at any time, thus it makes sense to use dynamic allocation for them (using malloc/free). However, it does have performance drawback. Particularly, I am not too fond of the slower call speed and memory fragmentation that can happen due to this.
One way to solve this is to implement a memory pool for the entities and components. This way, a new entity will merely draw from the pool, and a removed entity will just return to the pool. No new allocation needed. This is covered by the lecture series as well, though it is much later down the series.
This is actually a premature optimisation, which is bad. However, I thought it would be fun to implement a memory pool. That's why I did it.
**Note: this does not get rid of dynamic allocation usage. The library SC will make use of it for obvious reasons.**
The mempool struct can be seen in `mempool.c`:
```
typedef struct MemPool