Xentu game engine update.

It’s about time I give an update on how the engine is getting on, and boy has there been a lot going on!

Troubled Waters

I built the Xentu game engine prototype with C# .Net 4.6. This has worked great over the last couple of years during development. However discovering projects like Love 2D and Godot has shown I didn’t do enough homework. And it’s also made me question what my overall goal actually is.

Take Love 2D for example, it’s a Lua game engine that is simple to implement, doesn’t have the bloat of .Net hanging over it, and is fast. Then you have Godot which has it’s own user interface, 3D capability, and physics (to name a very few of it’s strengths). When you consider both have teams working on them, and are quite mature now, you can see how to me it is an absolutely terrifying wall to stare at!

At the beginning of this year having a lot more time than usual (thanks Covid-19) it became clear that I either needed to just scrap the project, or take it in an entirely different direction. I knew I still wanted to create a game engine, but it didn’t feel like I was being rational enough with the project. So I decided to take a cold hard look at my work, see what I should give up, and then focus on what I could salvage.

The Plan

So after a good 2 weeks in March, I finished writing a list of things I saw in Xentu that could still make it unique enough to be great. Here is what I came up with:

• Event systems are not standard, but Xentu has a powerful one built in.
• I built a true-type sprite font engine for Xentu, which still seems better than any I’ve found so far.
• The narrative engine I also built for Xentu is years ahead of others I’ve seen.
• Engines regularly state cross-platform credentials, but fail to document how, usually because it’s hard!
• Aside from Love 2D, most alternatives gain funding from morally questionable backers like Epic.

With that said, it is clear that Xentu still has a lot to offer, but regardless of what I do, competition will eventually need addressing. So I made a bold decision, drop my clutch of C# and rewrite Xentu in C++!

Between Now and Then

Did I mention that I didn’t know how to write C++? Well you know now! Anyway, so for the last 5 month’s I have basically been learning C++ from the ground up. It has been arduous, with some of the most difficult study in my life going into unlearning bad habits from C#. Memory management, correct placement for pointers, references, all caused me a fair few long nights. Thankfully I feel proficient enough now to start making future plans.

In May I took the plunge & started a new repository for building the Xentu port to C++.

Caught Up

So as of today I have a working prototype of the engine. The repository is not yet public, but once I have a stable alpha, I will announce it’s publication. The SpriteBatch class is still not functional, yet is a vital component. With any luck, the work I completed this weekend should get it working for the beginning of September.

This weekend my main focus has been on fixing the garbage collection model I chose. I discovered last week that I wasn’t using deconstructors correctly, which caused an awful lot of bother. I had originally used a model where I was implementing an unload() method on classes to delete heap allocated memory. I corrected the code to use deconstructors instead, but started getting an error code that threw me:

See the engine uses a binding script called Luna Five which takes care of a lot of boiler plate work for communicating with Lua. Something I never considered is that the script has it’s own methods for dealing with garbage collection!

Considering this new information, it turns out that the deconstructor for classes accessed in Lua were being called automatically. So when Lua goes out of scope, deconstruction can potentially happen twice, and you obviously can’t delete memory more than once!

To rectify this, I know I always want to manage deconstruction in C++, so I dove into LunaFive’s code, and did a few tweaks to allow disabling of automatic garbage collection when registering a class:

And voila! things seem to be a lot more predictable and stable. I’ve managed to rid myself of the unload() methods, and testing has shown me that things get cleaned up correctly. Being honest I could have just removed the GC part from LunaFive, however I don’t have a crystal ball, and can’t tell what might be needed in the future. Having a boolean argument seems a reasonable compromise all being said.

I also completed something that is not critical, but still an important part of the whole. I Implemented nested property access via Lua, which finally allowed me for the first time to load a texture via Lua. It seems like such a small thing, but remember it took me 5 months to get to this point, and honestly I cheered when I saw it work 🙂

Next Time

I have written a lot of code inspired by two open-source projects called SFML and Moony to enable SpriteBatch functionality. With the GC and nested access stuff out of the way I can concentrate on making it render something for the first time.