When writing the few component managers that are already being used, I noticed that I used a very similar approach for storing the data for all of them. This got me interested in whether I could abstract this approach as a new data structure, and base all future component managers on it. I wanted this data structure to efficiently store structures of simple data associated to entities, preferably giving a choice of how the data is laid out to work well with however it will be accessed. This took longer than expected to design and implement, due in part to how complicated the solution turned out to be as well as my university work taking priority. But now I have what I consider a good basic implementation. I call it a table due to how similar it is to relational database tables with primary keys, and it is contained in the open_sea::data namespace and the relevant pull request is available here.

Yesterday I have completed the first development version of basilisk, my custom programming language and LLVM frontend. This marks the first milestone on my road to learning about how programming languages work and how compilers are implemented.

In order to track performance of various parts of Open Sea, I decided to add a profiler. The idea is to track the execution time of certain sections of the code each frame. The requirements I had were both a text and graphical display, and ease of use. The text display is there to provide exact time measurements for comparison, while the graphical display shows how long the various sections take in relation to each other. Ease of use is very important for the same reason as with ImGui. It makes sure that I am never discouraged from profiling because it would involve too much work. The code is contained in the open_sea::profiler namespace and the pull request is available here.

While implementing a profiler for Open Sea, I have realised that I will need a data structure that reflects both the stack-ness of the call stack and the memory of a tree. In other words, a data structure that can be interacted with similarly to a stack — in order to be intuitive to use around functions and blocks of code — but doesn’t lose the data with every pop, so that I can then display that data and use it for optimisation.

To control cameras, I chose to use the new ECS. This feature is split into two parts: a system that makes cameras follow their designated entities, and system-like controls that move entities based on input. The code is split among the open_sea::ecs and open_sea::controls namespaces. The relevant pull request is available here.

To allow easier interoperation of different parts of the engine on game objects, I have decided to add an entity component system. I took inspiration from the ECS I designed and implemented for Open Desert and also the articles on the bitsquid blog. Given that this time I am working with C++, not Java, I decided to take as data-oriented approach as I could and use the language to its fullest. All code related to the ECS is contained in the open_sea::ecs namespace. The relevant pull request is available here.

With more complex models, it would be foolish store them in a hardcoded array of points. For those, you want to store them in a file and load that file when initialising the game. When testing the cameras, I decided to add this capability to Open Sea. I chose to write the loader myself, rather than use a library such as AssImp, to properly understand how this process works. To make it easier, I chose to support the simple Wavefront OBJ format. All code related to models is contained in the open_sea::model namespace. The relevant pull request is available here.

Cameras are a central part of rendering. That is why they are the first thing I have implemented for rendering in Open Sea. They are essentially boxes of data that spit out projection and view matrices on demand. The two currently implemented camera types are orthographic and perspective. Both are contained in the open_sea::gl namespace, as is their common base class. The relevant pull request is available here.

To simplify creation and usage of OpenGL shaders, I have now added the ShaderProgram class to the new open_sea::gl namespace. It represents a single shader program with attached shaders. The shaders currently supported by the system are vertex, geometry, fragment and (if the OpenGL context version is at least 4.0) tessellation shaders. The relevant pull request is available here.

Many parts of an engine require knowledge of how long the last iteration took. This then allows scaling of all changes in proportion to time elapsed and makes the experience more consistent with variable update times. To provide this, I have added the Delta Time module, contained in open_sea::time. The relevant pull request is available here.