OddMage

Data-Oriented Architecture: Building an Ultra-Performance, Cache-Aligned ECS Engine in C++

2026-06-04T00:00:00Z

The Hardware Reality of Modern Game Engines

For decades, game developers relied on object-oriented paradigms to model virtual worlds. We instinctively designed systems where actors, projectiles, and environmental objects were represented as self-contained instances of polymorphic classes.

In modern game engineering, however, this approach collides directly with the physical realities of CPU microarchitecture.

The Memory Wall and Cache Topography

Modern CPU performance is heavily bottlenecked not by clock speeds, but by memory latency—a phenomenon often referred to as "The Memory Wall." While a processor core can execute arithmetic instructions in a fraction of a nanosecond, fetching data from system RAM can take upwards of 100 nanoseconds (hundreds of clock cycles).

To mitigate this delay, CPUs use small, ultra-fast on-die caches (L1, L2, and L3). When the CPU requests a single byte from system memory, it doesn't just fetch that byte; it pulls an entire 64-byte chunk known as a Cache Line into L1 storage.

How Classic OOP Destroys Cache Efficiency

In a pure object-oriented engine, game entities are typically heap-allocated using standard pointers (std::vector<std::unique_ptr<Actor>>). This introduces two critical performance flaws:

Pointer Chasing (Discontinuous Layout): Heap allocators disperse memory arbitrarily across the system canvas. When your loop iterates through a list of actors, each pointer access jumps to a non-contiguous address in RAM, forcing a catastrophic sequence of L1/L2 cache misses.
Cache Pollution (Bloated Data): A standard Actor class contains polymorphic virtual tables (vtbl pointers), strings, bounding boxes, and state flags. If your physics loop only needs to modify 3D vectors (Position and Velocity), loading the entire Actor object into a 64-byte cache line wastes precious space on irrelevant data.

Data-Oriented Design (DOD) reorganizes data fields into flat, contiguous, tightly packed arrays, ensuring that every single byte fetched into a CPU cache line is immediately utilized by the executing thread.

Deconstructing the Entity-Component-System Architecture

The Entity-Component-System (ECS) pattern is an architectural implementation of Data-Oriented Design. It enforces a strict separation of identity, state, and behavior.

Architectural Core Definitions

Entity: A minimal 32-bit or 64-bit unsigned integer serving as a unique token. It contains zero state, no methods, and no structural logic.
Component: A plain old data structure (POD struct) containing exclusively primitive fields. Components are completely passive and contain no logic.
System: An isolated, stateless class containing logic loops. Systems query for groupings of related component arrays and process them sequentially.

Implementing the C++ Engine Core

Let's build a fully native, zero-allocation ECS core in modern C++20. We will enforce explicit cache alignment and use a packed swap-back array layout to guarantee optimal performance.

Step 1: Type Definitions and Identifiers

We define a clear integer type for our entities and use compile-time constants to establish maximum runtime bounds.

#include <cstdint>
#include <cstddef>
#include <vector>
#include <unordered_map>
#include <memory>
#include <iostream>
#include <chrono>
#include <thread>
#include <concepts>

using Entity = uint32_t;
constexpr Entity INVALID_ENTITY = 0xFFFFFFFF;
constexpr size_t MAX_ENTITIES = 20000;

Step 2: The Component Pool and Tightly Packed Arrays

To maximize performance, each unique component type must be saved inside its own flat, contiguous memory arena. We implement a ComponentPool that uses a Sparse-Dense Array mapping strategy paired with a Swap-Back erasure pattern to keep data elements tightly packed.


class IComponentPool {
public:
    virtual ~IComponentPool() = default;
    virtual void entity_destroyed(Entity entity) = 0;
};

template<typename T>
class ComponentPool : public IComponentPool {
public:
    ComponentPool() {
        // Explicitly reserve raw contiguous space to eliminate runtime reallocations
        _dense_components.reserve(MAX_ENTITIES);
        _dense_entities.reserve(MAX_ENTITIES);
    }

    T& assign(Entity entity, T component) {
        if (_entity_to_dense_index.find(entity) != _entity_to_dense_index.end()) {
            size_t index = _entity_to_dense_index[entity];
            _dense_components[index] = component;
            return _dense_components[index];
        }

        size_t new_index = _dense_components.size();
        _entity_to_dense_index[entity] = new_index;
        _dense_index_to_entity[new_index] = entity;

        _dense_components.push_back(component);
        _dense_entities.push_back(entity);

        return _dense_components[new_index];
    }

    void entity_destroyed(Entity entity) override {
        if (_entity_to_dense_index.find(entity) == _entity_to_dense_index.end()) return;

        // Tightly Packed Swap-Back Operation
        size_t index_to_remove = _entity_to_dense_index[entity];
        size_t last_index = _dense_components.size() - 1;

        if (index_to_remove < last_index) {
            T last_component = _dense_components[last_index];
            Entity last_entity = _dense_index_to_entity[last_index];

            _dense_components[index_to_remove] = last_component;
            _dense_entities[index_to_remove] = last_entity;

            _entity_to_dense_index[last_entity] = index_to_remove;
            _dense_index_to_entity[index_to_remove] = last_entity;
        }

        _entity_to_dense_index.erase(entity);
        _dense_index_to_entity.erase(last_index);

        _dense_components.pop_back();
        _dense_entities.pop_back();
    }

    T& get(Entity entity) {
        return _dense_components[_entity_to_dense_index.at(entity)];
    }

    T* data() { return _dense_components.data(); }
    size_t size() const { return _dense_components.size(); }
    const std::vector<Entity>& entities() const { return _dense_entities; }

private:
    std::vector<T> _dense_components;
    std::vector<Entity> _dense_entities;
    std::unordered_map<Entity, size_t> _entity_to_dense_index;
    std::unordered_map<size_t, Entity> _dense_index_to_entity;
};

Low-Level Mechanics of Swap-Back Erasures

The swap-back routine inside entity_destroyed is critical for data-oriented loops. Shifting all elements down when an item is erased costs $O(N)$ time and breaks pointer tracking. Leaving an empty hole forces your logic loops to perform frequent validation null checks, causing costly branch mispredictions.By copying the absolute final item of our dense array directly over the element being removed and executing a fast pop_back(), we maintain perfect data density in constant $O(1)$ time.

Hardware Optimization: Aligning Memory Layouts

To ensure that components load perfectly into CPU caches, we use C++20 explicit alignment attributes to align our vectors with a typical 64-byte hardware cache line.

Implementing Cache-Aligned Components

We structure our components using alignas(64). This guarantees that the start address of our structures in the pool arrays will line up beautifully on a hardware cache line boundary.


struct alignas(64) PositionComponent {
    float x;
    float y;
    float z;
};

struct alignas(64) VelocityComponent {
    float dx;
    float dy;
    float dz;
};

Constructing the System and Pipeline

Because our data vectors are strictly synchronized and packed, our processing systems can execute linear mathematical logic without jumping across pointer chains.

Designing the Kinematics Physics System

The PhysicsSystem takes raw pointers directly to our component storage pools. It skips entity lookups entirely and runs a highly optimized loop straight through the data arrays.


class PhysicsSystem {
public:
    void update(ComponentPool<PositionComponent>& position_pool, 
                ComponentPool<VelocityComponent>& velocity_pool, 
                float delta_time) {
        
        size_t count = velocity_pool.size();
        if (count == 0) return;

        PositionComponent* pos_array = position_pool.data();
        VelocityComponent* vel_array = velocity_pool.data();

        // High-performance pointer-increment loop
        // The compiler can automatically vectorize this loop using SIMD instructions (AVX2/AVX-512)
        for (size_t i = 0; i < count; ++i) {
            pos_array[i].x += vel_array[i].dx * delta_time;
            pos_array[i].y += vel_array[i].dy * delta_time;
            pos_array[i].z += vel_array[i].dz * delta_time;
        }
    }
};

Integrating Everything into the Engine Loop

Now, let's wire our custom C++ framework components together inside a standard production-grade execution application.


class EngineContext {
public:
    EngineContext() : _next_entity_id(0), _is_running(true) {}

    void initialize() {
        std::cout << "[Engine] Spawning 15,000 entities with cache line alignment...\n";
        
        for (size_t i = 0; i < 15000; ++i) {
            Entity entity = _next_entity_id++;
            _active_entities.push_back(entity);

            _positions.assign(entity, PositionComponent{ static_cast<float>(i), 0.0f, 0.0f });
            _velocities.assign(entity, VelocityComponent{ 1.5f, 0.0f, -0.5f });
        }
    }

    void run() {
        initialize();

        auto last_time = std::chrono::high_resolution_clock::now();
        size_t frames_processed = 0;

        // Simulation Loop running for testing purposes
        while (_is_running && frames_processed < 500) {
            auto current_time = std::chrono::high_resolution_clock::now();
            std::chrono::duration<float> elapsed = current_time - last_time;
            last_time = current_time;

            float dt = elapsed.count();

            // Run linear asset updates
            _physics_system.update(_positions, _velocities, dt);

            frames_processed++;
            
            // Throttle execution frame rate slightly 
            std::this_thread::sleep_for(std::chrono::milliseconds(16));
        }
        
        std::cout << "[Engine] Successfully executed " << frames_processed << " simulation updates.\n";
    }

private:
    Entity _next_entity_id;
    bool _is_running;
    std::vector<Entity> _active_entities;
    
    ComponentPool<PositionComponent> _positions;
    ComponentPool<VelocityComponent> _velocities;
    PhysicsSystem _physics_system;
};

int main() {
    EngineContext engine;
    engine.run();
    return 0;
}

Architectural and Performance Summary

By replacing classic object-oriented structures with an aligned, data-oriented C++ architecture, we unlocked several major performance advantages:

Zero Runtime Allocations: Component pools pre-allocate linear blocks of memory up front, preventing heap fragmentations during hot loops.
SIMD Vectorization: Because our primitive components are stored contiguously, modern optimizing compilers (GCC, Clang, MSVC) can auto-vectorize loops, leveraging hardware SIMD registers to process multiple operations in a single clock cycle.
Cache Line Perfection: Aligning elements to 64 bytes ensures data matches your CPU's hardware fetching architecture perfectly, maximizing memory throughput.

Shifting your mental model from "what is this object" to "how is this data read" is the key to building lightning-fast modern game engines that maximize every ounce of hardware performance.

Building a Simple Game Loop in C#

2026-06-03T00:00:00Z

What is a Game Loop

A game loop is the core of any game. It runs continuously, updating the game state and rendering the screen as fast as possible. Without it, nothing moves, nothing responds, nothing happens.

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>My First Webpage</title>
</head>
<body>

    <h1>Welcome to My Website</h1>
    <p>This is a simple paragraph of text on a live webpage.</p>

    <!-- This is a link to an external website -->
    <p>Learn more by visiting <a href="https://www.w3schools.com" target="_blank">W3Schools</a>.</p>

    <!-- This displays an image -->
    <img src="https://placeholder.com" alt="Sample Placeholder Image">

</body>
</html>

Every game you have ever played has one. The details differ but the structure is always the same.

The Basic Structure

At its simplest a game loop looks like this:

while (running)
{
    ProcessInput();
    Update();
    Render();
}

Three steps, repeated forever until the game exits.

ProcessInput

This is where you read from the keyboard, mouse, or controller. You check what the player is doing and store that information for the update step.

void ProcessInput()
{
    if (Keyboard.IsKeyDown(Key.Escape))
        running = false;

    if (Keyboard.IsKeyDown(Key.Left))
        player.velocity.x = -1;
    else if (Keyboard.IsKeyDown(Key.Right))
        player.velocity.x = 1;
    else
        player.velocity.x = 0;
}

Update

This is where the game logic runs. Physics, AI, collision detection, score tracking — all of it happens here.

void Update(float deltaTime)
{
    player.position.x += player.velocity.x * speed * deltaTime;
    player.position.y += player.velocity.y * speed * deltaTime;

    CheckCollisions();
    UpdateEnemies(deltaTime);
    UpdateScore();
}

Render

This is where you draw everything to the screen based on the current game state.

void Render()
{
    ClearScreen();
    DrawBackground();
    DrawPlayer(player.position);
    DrawEnemies(enemies);
    DrawHUD(score, health);
    SwapBuffers();
}

Delta Time

You may have noticed deltaTime in the update function. This is the time elapsed since the last frame in seconds.

Without delta time your game runs at different speeds on different machines. A fast computer runs the loop more times per second than a slow one, making everything move faster.

With delta time you multiply all movement by the elapsed time, so the game runs at the same speed regardless of frame rate.

float deltaTime = currentTime - lastTime;
lastTime = currentTime;
Update(deltaTime);

Fixed vs Variable Timestep

There are two common approaches to the game loop:

Variable Timestep

The update runs as fast as possible and uses delta time to compensate. Simple but can cause physics instability at very low frame rates.

Fixed Timestep

The update runs at a fixed rate, say 60 times per second, regardless of the render rate. Physics is stable and deterministic. More complex to implement.

float fixedStep = 1.0f / 60.0f;
float accumulator = 0;

while (running)
{
    float deltaTime = GetDeltaTime();
    accumulator += deltaTime;

    ProcessInput();

    while (accumulator >= fixedStep)
    {
        Update(fixedStep);
        accumulator -= fixedStep;
    }

    Render();
}

Conclusion

A game loop is simple in concept but the details matter. Start with a variable timestep, understand how delta time works, and move to a fixed timestep when you need stable physics.

Every game engine you will ever use has a game loop under the hood. Understanding it makes you a better developer regardless of what tools you use.