Why does XVE look so basic?

I've literally been inundated by a message about my XVE project, specifically calling out why I have the temerity to describe it as an "Engine when it looks do basic?"

My over simplification in reply being that an engine can be anything you please, the engine is simply the framework within which the content can execute.

 

This applies to Unreal, Unity, Godot all of them, if you have something which will load your models, compile/apply your shaders and render to the screen you have a graphics engine.  If you have a threading model, memory or allocation handling, logging, input, user interface... All these module pieces form an engine.

The reason I am investing time working in my own such project is to explore those modules in which I find my experience or knowledge needing expanding, where I wish to trial alternative approaches, keep up with emergent new techniques or processes.

And of course for the content itself to explore the content creation tools; for instance I am very much a Blender beginner, and learning fast.  I could not say this just three months ago.

 

The major advantage to me in performing this kind of exploratory work at home in my own time is of course that I take a confidence and an assuring confidence back to my real work, as a leader of a small team I feel I am equipped to jump into pair program and just help.  I feel equipped going over a diverse or new code base; for instance recently I explored the Dagor engine used by WarThunder and the Little Vulkan Engine by Brendan Gaela.

 

Chronologically XVE has gone over many internal milestones, long before I began posting anything to YouTube or this blog about it, including:

• CMake & Project Structure
• Coding Standards
• Git & Commit Hook integration for Jenkins Continuous Integration Builds
• Test Framework
• Module Design
• Base
• Renderer
• Data loading
• XML
• CSV
• Wavefront Obj
• Generated type definitions (a whole generator suite written in python
• Entity Component System
• Threading Model
• Thread pool
• Anonymous Async Dispatch
• Promise/Future Standard Exploration
• Memory/Allocator Models
• Slab Allocators
• Dynamic Allocators
• RPMalloc
• Standard Allocator API (Custom)
• Input Framework
• XInput/DirectInput
• SDL2 Input
• SDL3 Input
• GLFW Input
• Custom personal exploration

And only after all this did I begin exploring actual game content and systems and component and entity relationships to represent the game design concepts.

 

The engine becomes a tool, a tool to achieve the delivery of the experience we want our players to experience and enjoy, so they return time & again to our game.

 

The game is key, and if done right the player should never know what engine or framework is being used to deliver that experience to them.

Development : Simple Versus Complex

I have been reading some of Alan Turings works, specifically some of his work for the NPL in the late 40's and early 50's, before he went to Manchester in frustration with the NPL's lack of progress with his ideas.

One of the ideas Turing was pressing at the time was to do as much as he could in software, don't jump to hardware solutions; which at the time fixed the functionality of the machine to a single purpose; instead he wanted a general computing device he could put to any uses he desired.

Today the average programmer, hobbyist or indeed employed software worker, such as myself, don't have the opportunity to define new hardware for a bespoke task, indeed the machines we are driving are far more powerful than Turing ever imagined and we can do as Turing suggested, we can write software to get around an issue.

You need encryption, why pay to plug in a dongle doing this, when the processor you have is equipped to do the task for you, indeed some processors even have encryption instructions and powerful parallelism built into assist in such work!

So today's lesson is, take on board Turing's ideas, do in software as much as you can, even if you want to later move to real hardware emulate your idea now.  Here's a very good example:

nVidia's emulation lab is an extreme example, however, it is indicative of the kind of problems we are meeting today as older engineers are coming away from dedicated hardware devices (because their machines were too slow in the 1990's) and we have today's extremely powerful machines right there at our finger tips.

Why does this exist?

Last week I set about looking at a quite old system (circa 2008 it was last attended to) it contains a message passing system, which allows passing of messages (events if you will) between producers in any process to consumers in any other process subscribed to the service.  It did this with a windows service driver, which called down into a USB dongle to queue the message.

The consumers then polled the USB device (round robin style) to determine if the next message was for that consumer... You might imagine this was extremely slow.

It was also very complex, the code within the USB dongles was not mutable; being set in silicon; and the consumers could end up locked out of the service queue by a message being present for a consumer which was not able to consume the message.

This clearly needed replacing.... So, I had to look at it, a single afternoon, it was just extremely complex inside, so one had to take a step back, don't look at the contents of the code, look at the API, the functions being used....

The producer code relies on just three functions and the consumer relied on a thread safe queue which was woken up from a spin wait to call the registered consuming function... Not rocket science.

I set about writing new code with a very simple UDP server and clients, taking the message in, converting it to XML and posting it to the loopback IP Address of the master UDP listening port which then sent it out to the listening consumers on their loopback IP and port number.

Voila, in an afternoon, I had replaced five years (ish) of complex, hard to maintain code, with a working prototype of a solution.  And it dropped straight into place.  The dedicated, slow, old, hardware could be unplugged and the system just carried on as it always had.

The customer for this product is delighted to see it running faster, and the overhead of the hardware costs being removed.  All by simply doing in software something which was being offloaded to hardware in yester-year.