Brane Engine Weekly Update #3

Hi everyone, welcome to the weekly update that took a month and a half since the last update to get published! My excuse is a new job and the start of a new school semester and it took me a bit to get my schedule back into order. But we are back with (hopefully) weekly updates showing what’s been going on behind the scenes.

This week we only have 2 big updates and a smaller one:

The main update is the introduction of the Runtime class. So far I’ve been coding the engine in separate modules, so we have the graphics module, the assets module, the ECS module, etc. But they were only “Modules” in the way that I treated them and in the end they were just separate classes with defined jobs. I’ve also been trying to figure out a cohesive way to handle calling run/update methods on everything since just having a custom raw while loop for every executable isn’t the best. I decided to fix both of these issues with the addition of a dedicated runtime. This runtime contains a list of modules and a “timeline” of sorts, so at the beginning of the main function I can define time blocks for functions to be executed inside of, and add modules. It’s much better than the reference passing spaghetti code I had before:

before
after

Ignore the weird tabs, GitHub is trying to make me look bad.

The second big update is that I’ve added a lot of functionality to the networking system. Most notably a way to send generic requests and define “streams” of data. These make it much easier to add anything that requires any sort of networking that I might need. Requests work very similarly to HTTP requests in that they can be sent and then have the response automatically sent to the right place for them to be dealt with. So I can set up a listener for an asset request on the server-side, and then the client is able to send a request of type “asset” and then get a response with the data that will be handled by a callback that’s set when the request is sent. Streams work similarly, any connection can be told to start listening for a certain stream, and then all the data sent to it will then be sent to the said stream. This makes it super easy to stream multiple different assets (and other data in the future) all over the same TCP connection without getting them mixed up.

Lastly but not least-ly I’ve started working on an editor build so here’s a screenshot of just the ImGui demo window running:

Final honorable mention, refactored the waiting system of the Thread pool so it schedules stuff a little faster while not using 100% of the CPU.

Liked it? Take a second to support WireWhiz on Patreon!
Become a patron at Patreon!