v0.8.7 #23

richardbiely · 2024-09-23T17:00:58Z

richardbiely
Sep 23, 2024
Maintainer

This is an important bug-fix release with some interesting internal changes.

First and foremost, despite all the unit tests and memory sanitization, some nasty bugs made it through which have been addressed now. Most of them were logical errors, some were more involved, though. The list of fixes is quite extensive so make sure to update. The core should be very stable now.

A few smaller features were added to the project to make your live easier.

Among them, implicit pairs:

ecs::World w;
ecs::Entity e = w.add();
// Old way of adding a pair to an entity e
w.add(e, ecs::Pair(start, pos));
// You can use a simpler notation now
w.add(e, {start, pos});

Component layouts are now defined via GAIA_LAYOUT. The previous version has been deprecated and is no longer recommended:

struct Position {
  GAIA_LAYOUT(SoA); // Treat this component as SoA (structure of array)
  float x, y, z;
};

The query engine started transitioning to a virtual machine. What this is means is that before the query is first run, it breaks the process into a sequence of specialized instructions in the process called compilation. This eliminates the need to run some logic every time a new archetypes is encountered and makes queries more efficient. The virtual machine is going to keep improving over time and will make queries even faster. It will also make it easier to extend the query engine significantly.
One big new feature, although still only in preview, is the introduction of systems as entities. An undocumented way to use systems until now was:

class MoveSystem final: public ecs::System {
  ecs::Query m_q;

public:
  void OnCreated() override {
    m_q = world().query().all<Position&, Velocity>();
  }

  void OnUpdate() override {
    // Update position based on current velocity
    m_q.each([&](Position& p, const Velocity& v) {
      p.x += v.x;
      p.y += v.y;
    });
  }
};

...
ecs::World w;
ecs::SystemManager sm(w);
// Register the system in the manager
auto& mySystem = sm.add<MoveSystem>();
// Disable the system
mySystem.enable(false);
// Enable the system again
mySystem.enable(true);

while (!terminate_program) {
   // Run all systems on the manager
   sm.update();
   // Handle various world-specific stuff (GC, defragmentation, finalize deletion etc.)
   w.update();
}

Systems can now be defined as entities:

SystemBuilder mySystem = w.system()
  .all<Position&, Velocity>()
  // Logic to execute every time the system is invoked.
  .on_each([](Position& p, const Velocity& v) {
    p.x += v.x * dt;
    p.y += v.y * dt;
    p.z += v.z * dt;
  });


// Retrieve the entity representing the system.
Entity mySystemEntity = mySystem.entity();
// Disable the entity. This effectively disables the system.
w.disable(mySystemEntity);
// Enable the entity. This effectively makes the system runnable again.
w.enable(mySystemEntity);

// The system can be run manually ...
mySystem.exec();
// ... or it can be run as the world seems fit
w.update();

This will allow systems to be queried and create complex relationships among them. For instance, you will be able to tell "give me all systems that operate on XYZ and turn them off", or "give me all systems which are a dependency of this one". This has many practical applications in debugging, monitoring and more which we will get into once the system is fully implemented.

Another preview feature is the introduction of a new storage type for components. So far, only archetype storage has been used. Although great in many things, archetypes are a bit slower when it comes to adding/removing components because content of all entities belonging to archetype A needs to be moved to archetype B. To mitigate this issue a new sparse storage made its way into the project. A packed array or a sparse set storage can be used to store components which are likely to be added and removed or if stability of reference is required. Components living inside the sparse storage never move and thus they are fast to add or remove.

struct SparseComponent {
  GAIA_LAYOUT(Sparse); // Store the component in a sparse storage
  uint32_t id;
  uint32_t data;
};
// Define a comparison operator
bool operator==(const SparseTestItem& a, const SparseTestItem& b) {
	return a.id == b.id && a.data == b.data;
}
// Define to_sparse_id function which extracts a unique id among all SparseComponents
template <>
struct gaia::cnt::to_sparse_id<SparseTestItem> {
  static sparse_id get(const SparseTestItem& item) noexcept {
    return item.id;
  }
};

Data structures are implemented, they are not connected to Gaia yet, though. I will write more about this feature and its implications once it fully lands. For now, it can be used like this:

cnt::sparse_storage<PositionSparse> arr;
arr.add(SparseComponent{100, 0});
arr.add(SparseComponent{200, 1});
const bool has100 = arr.has(100); // true
arr.del(100);
const bool has100 = arr.has(100); // false
const auto data = arr.operator[200].data; // returns 1