Category Archive

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.

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.

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.

To allow easy debugging of Open Sea at runtime, you need a good debug GUI. One of the most important requirements is for it to be easy to expand. You don’t want the debug GUI to be a substantial part of development of a new module. To that end I have decided to use Dear ImGui. It is an immediate mode GUI that I first saw in a GDC talk. Module integrating this library with Open Sea is contained in open_sea::imgui (omitted from identifiers below). The relevant pull request can be found here.

Another new module for Open Sea is the Input module. It builds on top of GLFW’s input using the Boost.Signals2 library. It allows easy access to signals for input of the global window defined in the Window module. This module is contained in the open_sea::inut namespace (omitted from identifiers below). The relevant pull request can be found here.

Recently I finished a new module for Open Sea, the Window module. This module is an abstraction over the GLFW library and is contained in the open_sea::window namespace (omitted from identifiers below). The relevant pull request is available here.

First part of Open Sea is the logging module, which is a layer of abstraction over the Boost.Log library. It sets up easy logging into a file with a fallback being the console. The whole module is contained in the open_sea::log namespace.

Over the past few months, I have been seeing my lack of experience with C++ as more and more of a problem. I realised that in order to do what interests me properly, I need to learn that language and get as good as possible with it. I like Java but it has some big disadvantages. Mainly less possible optimisation which results in worse performance, and the requirement for everything to be object oriented, which causes some overhead when implementing concepts that don’t necessarily need to be objects.

During the implementation of the Entity Component System, some things had to be changed from the design described in the previous post. In this post I will summarise these changes and the reasons for them. A lot of the reasons stem from my desire to keep the code simple and modular. As this article goes out, the changes will be merged from their feature branch into the master branch of that project repository.

As I have described in the Components post, I have decided to completly redesign the current entity system. The new solution will follow the Entity Component System pattern. As this is an extensive change to the code which will also be the base for a lot of future code, it needs to be planned out first. In planning this, I will use various articles, books, and talks available online. Any significant sources are linked at the end of the post.

I am already using a simple entity system in the project. Currently this is done by inheritance. As I am working on adding animation to the current implementation of sprites, I am starting to see that I need more flexibility. From what I’ve seen in other engines, this kind of flexibility could be provided by using a component system instead of inheritance. As this would be a big and involved change, I want to first explore how I can best implement it.

Open Desert is my OpenGL sandbox. It is written in Java and uses the LWJGL 3 for bingings to the native libraries. The aim of the project is to create a functioning game engine. Currently it is strictly 2D, with the plan to add 3D capabilities at some point in the future.

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.

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.