Project type: C Simulation
The repository for the boids simulation.
The ecs library i wrote this for.
My second implementation of a boids simulation. This time written in C using a combination of SDL2 for rendering and a self-made ecs library for object management. The program includes a ui window which allows users to modify the settings of the boids at runtime.
This was made as a stress test of a pure C entity-component-system library I was building for myself. During the development of the boid simulation i managed to improve the ECS it was build around by multithreading it. As well as improving lookup times through binary search. Both of which are rather rudimentary improvements i wanted to make, but the stress test not only made it more obvious they were needed, but also made it much more measurable when they worked.
The program is split into a set of distinct submodules. The ecs, adb, ui, engine and sim modules. Of these modules the adb and ecs modules are entirely standalone, the ui module depends only on SDL2, the engine is dependent on all others except sim, and sim is dependent on engine.
NOTE: Most of these modules were developed separately and as standalone libraries. As such, they have vastly differing naming conventions. Still, each module is internally consistent about its own naming scheme. I just tend to switch style every project. For clarity, the ecs and ui modules use camelCase while the adb, engine and sim modules all use snake_case.
The engine module provides the program's entry point and update/render/event loops. It communicates with the sim by declaring three functions as extern without defining them. The sim then defines them allowing the engine to call functions from the sim. The functions in question are:
The sim module is the only module that actually interacts with anything boid-specific. Whereas the other modules are more so supporting of the simulation. The sim can be divided further into the part that interacts with the engine module, and the part that actually models and simulates the boids. The part that interacts with the engine is responsible for registering components and systems with the ecs, loading assets, and spawning the boids.
The second part of the sim module are the functions that make the boids behave the way they do. The ones that run as systems from the ecs all follow the signature of an ecs system function. They take in a list of entities, a list of the corresponding component masks, the number of items in both lists, and the delta time of the current frame. They then loop over the entities and perform specific actions for each one. In order to avoid looping over every boid in the simulation every frame, for every boid. The boids cache boids that are within the range of the behaviour with the furthest range.
When the boids that are close enough to interact have all been cached, the actually modifying systems start running. As a demonstration is the separation system, which keeps the boids apart from eachother to avoid all of them forming a singularity. For each boid, the system loops through all nearby boids, keeping a running average of the positions of each boid nearby enough to be within range. After all nearby boids have been accounted for, the boid's velocity is adjusted to move away from the calculated average.
Cohesion and alignment are similar enough that i wont place them here. Cohesion is the opposite of separation, and alignment is practically the same but with velocity instead of position. The mouse does the same as cohesion but with the mouse, and thus without the need for an average. The wall behaviour pushes the boids back onto the screen when they exit it.
The entity-component-system (ecs) module manages the runtime object model where Entities are numbers, Components are blocks of memory attached to an entity and Systems are function pointers with a component requirement. This is the library that the boids where made to test. The below code consists of snippets showing initialization and uses of components systems and entities.
The asset database (adb) module is the module responsible for managing asset data. So it has functions for loading data from files, getting loaded file data, and releasing data after it is no longer needed. To keep this module generic, it has runtime defined rules for managing files through file handler functions.
The ui module is based on the immediate mode graphical user interface (imgui) paradigm. This is a paradigm where there is no intermediate storage between the gui and the data. The gui directly modifies the data and vice versa. In my implementation this is done by sending the gui functions pointers to the data they represent as parameters.
Project type: C++ Simulation
My first version of a boids simulation. Written in C++ with sfml.
I worked on this for about week inspired by the lessons on steering behaviours at school.
The boids themselves are primarily a position, a velocity, a mass, and a collection of behaviour function pointers. These boids are then stored in a vector and each of the behaviours is run for each of the boids, resulting in the demonstrated movements.
As previously mentioned, the boids all store a collection of behaviours, represented by function pointers. These function pointers take as input a context object representing the program state at the start of the frame, and output a desired change in velocity. The original boids paper describes cohesion, separation, and alignment, so these are the main behaviours implemented.