BEngine

Last Updated: 22/10/24

Preface: This is an on-going WIP from a more stable previous version. This is more of a testing bed for several new structural ideas over a structurally sound, prototype ready engine. If you do want to have a compile and run of your own (tested for x64, debug + release), you can download from the link below to have a closer look at some of my ongoing work. Feel free to explore, test and modify as you like.

What is the “BEngine”?

The “BEngine” is a 2D-focused, DX12 C++ engine, personally developed by me over the years (since university). It’s had several different iterations and rebuilds around projects or new features and concepts I’ve wanted to try out. This latest version (whilst more experimental than previous), is a culmination of some of the projects you can see elsewhere in my portfolio, and an exploration of some newer ideas.

Whats new in this current version?

The experimental side of this version is to do with a general code review of the baseline, and into try implement better structural support for extendable features. It’s a bit of a mixed bag (most things have had revisions or a little touch up at least), but here are some of the highlights:

New Actor Interface + Module System

The experimental side of this version is to do with a general code review of the baseline, and into try implement better structural support for extendable features.

Taking inspiration from Unreal Engine, the first major change is an overhaul to the Actor Interface, where I want to try conceptually capture the Uobject from UE, but at much more minimal/restrained form for now. On some level, the older version did achieve this, but acted more like an Aactor with baked in components (as per the UE example), like sprites/animated sprites. The update aims to bring it back a layer, acting as a baseline class that all “in world” objects can be derived from ultimately.

Following on with that inspiration is the Module system (or Components). Exactly like UE, anything that could conceivably be on a game object, will be based out of the base module class. This part certainly needs more cooking, especially in how to manage the hierarchy of module and proper communication between module-to-owner and module-to-module (if even necessary).

Whilst at it, but certainly more experimental, I added new update calls in additional the original, single update call, to open up much better control, logic and performance down the line.

Box2D Integration

Box2D is 2D Physics Engine developed by Erin Catto. It’s uses here are two-fold:

I’ve also been working on integrating Box2D (just parts of it for now) to fill in some gaps and solve some lingering issues.

Box2D provides some (if not all) of the collision solutions that I am currently looking to solve, through from basic collision detection, resolution (as far as physics are concerned) and basic mechanisms to build a callback system around it. On the collision front, it allows me to defer more attention to other systems without the unnecessary limitations of what collision options I’ve produced so far (which are naturally inferior to a dedicated library). And on the callback side of things, it gives me a comparable option to UE, letting me build a framework around it to allow objects to communication on certain collision events, with some starting work on that done already.

I’ll moving on to further integration, particularly to leverage the physics side of things later down the line, once the fundamentals its current usages are firmly in place.

Early Work on SpriteBatch + Graphics Pipeline Updates

DirectXTK, and it’s SpriteBatch class, has been throughly leveraged throughout most engine versions. It’s particularly efficient for simple sprite rendering (and lots of them), with my own animation/sprite classes being used to fill in the rest of the basics. However, its been a little limiting on what I have allow for graphically through shaders due it’s rather rigid pipeline options.

First steps on getting around that has been working on a wrapper class to extend some of its behaviour in simple way to get around the limitations, such as using bound functions to modify what happens in the render setup with that particular batch. This opens up setting additional const buffers, alongside setting custom shaders and root signatures in the setup process. I hope for this to enable additional texture options down the line, like normal mapping/blending (pending proper testing).

Still a lot of work to do in this regard, but it should hopefully enable additional texture options down the line, like normal mapping/blending (pending proper testing), and failing this, a more hand-on replacement may be on the cards.