top of page
ALEX ILUKHIN
Game Software Engineer - Real-time Systems
Axis Game Engine
About
I initially developed this game engine in college, and I've been continuing it as my hobby project. I implemented real-time systems and runtime libraries covering animation, graphics, asset and object management, math, a custom data structure, and more.
Project Info
Role: Game Programmer
Team size: 1
Time frame: ~8 months
Tools: C++, DirectX 11, Perforce, Visual Studio, Google Protocol Buffers, Tiny GLTF
Overview
The goal of this project was to develop real-time systems and runtime libraries that would all eventually coalesce into a game engine. I go into more detail about certain systems below, but here is a quick overview of what I worked on.
-
Asset Management and Google Protocol Buffers
-
Textures, meshes/models, animations
-
Offline converter for translating data assets to engine specific runtime format
-
-
PCS Tree Library
-
Hierarchical tree structure for game objects
-
Custom iterator
-
-
Manager Library
-
Provides iterator and container (Linked List) for manager classes
-
-
File Library
-
Wrapper for Win32 file system
-
-
Math Library
-
Vectors, Matrices, Quaternions, and Trig operations
-
Hinting system to improve peformance of matrix operations by a factor of ~4
-
-
Graphics system
-
Texturing and Lighting
-
Camera management
-
Sprites
-
Primitive meshes - cube, pyramid, diamond, cross, and sphere
-
3D models/meshes
-
-
Animation system
-
Uses PCS Tree for hierarchical bone structure
-
Currently under construction but enough to show the basics
-
Asset Management and Google Protocol Buffers
The engine makes use of a separate converter solution to convert different kinds of assets into a centralized runtime format that is specific to this engine. This is advantageous because it's much easier to maintain engine performance when it doesn't have to care about the many different file formats for all kinds of assets which naturally leads to a lot of complexity on how to interpret what's what. Textures, primitive meshes, models containing 1 or more meshes, and animations are supported.
The other aspect to this is how the assets are processed and converted into the engine's runtime file format. The GLTF library is used to read the asset data, and google protocol buffers is used to store and convert that data into the engine's runtime file format and then also unpack it on the engine side
Object Management and PCS Tree
One of the ways objects can be managed is supported by the manager library. Any manager class specific to the engine or game can inherit from ManBase which gives it a linked list container of reusable nodes along with its own iterator for traversal. New node classes inheriting from NodeBase have to be created with a pointer to the specific kind of object they keep track of.
The manager class also gets to take advantage of object pooling to recycle the nodes. It has an active list and a reserve list. The active list holds nodes with specific objects that are currently being used by the game/engine, and the reserve list holds empty nodes waiting to be used. On creation, a manager can be given an optional parameter to fill up the reserve list with a desired amount of nodes.
Some examples of how this is currently used in the engine are the game object, texture, mesh, image, and shader object managers. The UML diagram below gives an idea of how manager functionality is structured.
The PCS (parent-child-sibling) tree is a custom data structure for managing hierarchies of game objects. A simple example would be an aircraft carrier object as the root with jets and other objects as children/siblings on the deck. If something happens to the aircraft carrier that effect can easily extend to the objects associated with it. This kind of hierarchy is also useful for manipulating bones for animations.
The image on the left shows the basic structure of the tree. Each node has its own PCSNode pointers to its parent, child, next sibling, prev sibling, forward, and reverse nodes along with helper functions associated with them.
The image on the right shows what the forward and reverse data fields of each node look like with the given example layout. These fields are used by the forward and reverse iterators. The forward and reverse pointers which are initially nullptr are set or modified when objects are inserted or removed from the tree. This means the iterator performs faster during runtime because it doesn't have to care about setting up the forward/reverse pointers with the tradeoff of having the insertion/removal functions take a bit more time on the tree.
The way this works with the engine is the base game object class inherits from PCSNode which allows objects to be manipulated into this structure. A manager class could have it's own PCSTree and insert objects into it depending on the use case.
Math Library
The Math library supports vector (vec3 and vec4), matrix (mat3 and mat4), quaternion, and trig operations. A common operation for matrices is getting the inverse of a matrix. Getting the inverse is a heavy operation, but there are times where the properties of a matrix don't require the full inverse operation and can instead take shortcuts. This is the basis for a hinting system used by matrices (specifically a 4x4 affine matrix) to speed up the inverse operation whenever possible. The last 3 bits of the 16th float are used to set a hint flag. The reason why the 16th value is chosen is because it's consistent (always 1). An affine matrix is still accurate up to 6 decimal places to the right, and since floats are an approximation anyway this is an acceptable tradeoff.
The image on the left shows the hinting enums and support functions. A matrix that is only a rotation matrix will have the corresponding Rot enum (0001), a matrix that contains a rotation and a translation will have the RotTrans enum (0011), and so on. Bitwise operations are used to check and set the hint enums.
The image on the right shows an example of how a shortcut can be taken. When the inverse of the matrix is requested, it checks the hint and determines how to proceed. A general matrix will go through a full inverse operation while a rotation matrix for example only requires a transpose, so that gets done manually. This greatly speeds up the inverse operation in many cases by about a factor of 4 and up to 5 in release.
bottom of page