SanderMertens

// Draft for manual creation of deferred command queues.
// There are three basic requirements for the API:
// 1. Allow for population of a command queue from external source (not flecs API)
// 2. Record operations and take control over how they are flushed
// 3. Allow for pushing operations to different queues
//
// All requirements must work in multithreaded applications, and for applications with multiple synchronization points.
//
// High level design:
// - Application can create a defer context. A single defer context contains a command queue per thread.

SanderMertens

typedef float vec3[3];
typedef float quat[4];

typedef struct mat4 {
    float value[4*4];
} mat4;

struct transform {
    transform() 
        : pose({ })

SanderMertens

V3 roadmap

This is a list of planned features for v3

Declarative APIs

Less but more powerful API calls, following a more declarative design as described here: https://gist.github.com/SanderMertens/40bf6cd98dc658443651125e6dee5c28

Hybrid storage

A hybrid model that supports archetype and sparse set storages. Applications will be able to upfront specify which components are stored in a sparse set, and which components are stored in an archetype. The API will work transparently with either storage. Queries will transparently query across sparse sets & archetypes if needed.

SanderMertens

// Draft for low-level macro-less API
// 
// The goal of this draft is to explore a full-featured minimal API that does not rely on macro's. That should make it easier to port 
// flecs to other languages, and allow for more straightforward integration with other frameworks / engines. This is not meant as a
// full replacement for an application-facing API, though should be able to coexist with one.
//
// Inspiration for naming conventions & declarative design comes from Sokol Gfx

// Create world as usual
ecs_world_t *world = ecs_init();

SanderMertens

struct Threshold {
    float value;
};

struct Blur {
    float radius;
};

struct HBlur : Blur { };
struct VBlur : Blur { };

SanderMertens

v2.2 benchmarks

Measurements are per operation. Measurements for bulk operations are scaled to the number of entities. To minimize the impact of scheduling and improve reproducibility, each measurement is done N times, for which the minimum and average time are calculated. The minimum time is the most reproducible, as this is the time with the least impact from the OS scheduler. As the times for most operations are measured in nanoseconds, each measurement measures an operation executed many times (typically 1 million). This minimizes the impact of clock accuracy issues and the overhead of measuring time.

ns = nanoseconds, us = microseconds, ms = milliseconds

Entity creation	Min	Avg
flecs.new_id	9.459 ns	11.009 ns
flecs.new_id_recycle	2.763 ns	3.198 ns

SanderMertens

#include <transform.h>

typedef float vec3[3];
typedef float quat[4];
typedef struct mat4 {
    float value[4*4];
} mat4;

typedef struct transform {
    /* Individual components */

SanderMertens

info: bootstrap
info: | threading available
info: | time management available
info: | bootstrap core components
info: | | table [EcsComponent,6,CHILDOF|280] created
info: | | table [EcsComponent] created
info: | | table [Type] created
info: | | table [Name] created
info: | | table [CHILDOF|280] created
info: | | table [Name,CHILDOF|280] created

SanderMertens

World

---

World creation (n = 10):

Framework	Measurement
flecs	0.005501 World creation

SanderMertens

Here are some generic design guidelines (emphasis on guidelines, not rules):

• When building a new feature, start with the components and spend time thinking about how the components will be used (how often are they written/read, who owns them, how many instances etc)

• Design components so that they have a single purpose. It is much easier (and cheap) to combine two components in a query than it is to split up components, which causes a lot of refactoring.

• Don't over-generalize. If your code has lots of branches it is possible that you're trying to do too much with a single component. Consider splitting up components. It's ok to have multiple components with the same fields, if this makes your business logic simpler (and faster).

• Think twice before adding collections to components. Collections are OK if the contents of the collection are meant to be interpreted as an atomic unit, but if the individual elements must be interpreted in a standalone way, consider creating separate entities instead.