Disclaimer: This is an early version of a mid-overhaul of the engine. Nothing is set in stone and there may be some loose threads or yet to be thoroughly tested structural elements (such as how things are accessed or managed etc). It is however structurally sound enough to compile (x64, debug & release) and comes with a simple demo on what I have been currently testing (physics, animation and UI functionality). Naturally, you’ll find some WIP code alongside the demo, but feel free to explore, test and modify as you like.
Repo Link: Click Me!
Engine Background & Goals
The “BEngine” is a long standing project started during started during university to create and manage an 2D focused engine framework that can support a growing list of techniques and features. It’s had several different versions and overhauls over the years, through SFML, to DX11 and now DX12, each with new lessons learned and applied.
There a few main goals as to why I am maintaining this engine:
(1) Get fundamental learning and practice with techniques first-hand without commercial engine reliance or pre-built libraries (where practical/desired), applying them as part of projects or as academic adventures.
(2) Gain a broad range of experience that comes with maintaining and improving different engine aspects (graphics, audio, systems etc), on top of game-specific tasks and challenges.
(3) Keep the door open to developing an engine (or engine derivation) that allows for specialised options down the line (potentially in the vein of Fez, or Noita).
New Features
There are numerous changes to be found in this new version, from reworks of existing structures, fundamental overhauls, general code revision, and brand new additions. Lots of this is still WIP and because of the broad nature of the changes, I am sure I’ve missed something things, or will need to make changes again due to misunderstanding some areas or design oversights.
That said, here are some of the highlights:
Actor Interface Overhaul & New Module System
The original interface worked well enough on the basic fundamentals, like providing a common class for good polymorphism to take place with game objects and entities. However, it was prone to being tangled up with project data that may be best visible at that level, as complications with how the “module” system was implemented at the time.
The first major change was implementing a comprehensive module system that was scalable, extendable, and non-intrusive to add to. The idea takes a leaf out of Unreal’s book in how it uses its Component System. Now modules are created out of their own interface class with appropriate virtuals for regular use, alongside additional functions and data to be able to safely cast the modules for specific data access.
The next major change is related the overall flow of the engine, with several new Update function calls to better break-up update cycle into appropriate stages (with changes made elsewhere to accommodate).
The last change is the inclusion of several Callback functions that related to collision events, which relates to the next section.
Box2D Integration
Box2D is 2D Physics Engine developed by Erin Catto. It’s uses here are two-fold:
(1) Provide the engine with a comprehensive, well functioning physics and collision option (replacing previous attempts at hand-built collision options, with some exceptions).
(2) Help fill in a key missing element of the engine; a Callback System.
One of the longest problems with the engine was managing collision in a performative and sound way, with attempts at this done by implementing my own collision methods. Whilst they worked in the detection sense, resolution has always been a bit of a thorny issue that Box2D will help solve. This opens up much better options for any physics-based projects in future.
It also serves as the spine of the callback system, providing a vitally missing bit of functionality in reacting and resolving collision events between actors much more broadly, with customisation options on how that happens.
Integration of the library is still an on-going process (as I am also still learning how to use it), but much of the fundamentals are in place and additional features are slowing incoming.
Early Work on SpriteBatch Functionality Wrapping
DirectXTK SB has been a mainstay in the engine for practically all of its lifetime. It’s an efficient and simple method of rendering sprites (and lots of them) exceptionally well. There is however a problem in how much it allows you to customise the pipeline outside of its expected parameters, and the limitations that puts on doing more with because of that.
To get around that, whilst still using it as the primary go-to for basic sprite work, I’ve started work on extending its behaviour by working around those expected parameters. The first step for this was wrapping up the SB class in a new wrapper class with a bind-able function to be able modify what happens during the rendering process with the particular batch. This opens up setting additional const buffers (alongside setting custom shaders and root signatures in the initialisation process), and hopefully additional texture for normal mapping/blending in future (pending proper testing).
To support this all better as well the engine now renders primarily using Render Groups. Objects can submit themselves to RG’s (typically done in the PreRender step) which delegates much more control to the object in how it renders itself. These groups are now housed inside the graphics manager where they can be accessed as needed. The previous rendering method is now more of a legacy method (still supported for testing purposes).
Better Graphics Pipeline Customisation
As a bookend to the changes, I also wanted to update how the rendering pipeline works at the Game class level, and allow for better control from the Mode level as well. To that end, 3 major sections of that pipeline (PreRender, PostRender & OnResize) have been setup to use bind-able functions to be able change how the pipeline works much more freely whilst maintaining a simple baseline to work with.
Benjamin Kimberley 