Home Game Engine : Physics Debugging Tool Progress

The last week has been invested into the Physics Debugging tool, it connects to the main game world; whether that is running in the client with it's own vulkan renderer, or into the server, for I am planning to have the server be authorative over player position at least, to prevent some of the strange hackery doo of the client being in charge.

Here's a silent video of that progress, as I'm recording from my Ryzen Workstation and I don't have a mic in here.

There is actually a lot going on in the background here, though the scene looks largely unchanged.

The most obvious addition since the last scene update is the replication of the rotating object, which is just a box, but that is being rotated on the client.  My controls here send a message to the client, which then sends the status update to it's GameObject.  The same frame the GameObject queues a message out and the scene updates to the physics representation; which means I get near real time (minimum of network delay + 1 frame) of the replication of an object back and forth.

However, I don't plan on expanding that too much, the number of messages is getting silly.  For example, I have an object for a position update (3 floats) then I have one for a position and a rotation (6 floats) and then a whole other one for position, rotation and scale (9 floats) which I call a transform.  I could just replicate a transform each frame, but then the amount of data gets very much larger.

I also have flash backs of delivering data from a server on a provisioned box, where you pay by the megabyte per monthly usage (and I honestly don't know why I couldn't host a service like this server publically on my massive 500mbit home fiber, which has no cap on data, it's all I can eat) but practically, I'd not like to host this here, except for debug, and if I were to make a game, it'd need to be on an AWS instance or something.

Anyway, that's all very much future stuff, my next problems are all about the game, improving and cleaning up my game object authoring, improving my model making skills (I might actually have to double down and actually learn Blender) and the working out a few issues I know exist in my control scheme.

More about all that in March though, for the rest of February, I have to tidy this stuff up.

If you want to know more, or follow some of my other older projects and videos, my YouTube Channel exists https://www.youtube.com/@LordXelous and of course this blog is always ticking over!

That Subscribe button really helps!

Home Engine - Bank Holiday Camera Controls & More Models

After the silence earlier in the year I'm so happy to be blogging more often, and I hope you are all enjoying it too; I can see some regulars popping by and a few new faces in the stats list; but still far too many of you are totally anonymous, drop me a comment!

Anyway, what I have I been up to?

Well, under the hood I've totally revamped how the uniform buffer objects are passed to the rendering operation in the vertex shader.  I've also moved the view and projection matrix calculations into a nice camera system class, so they're contained and sensible to use.

As a result I've then added some key bindings to move forward, strafe and rise/drop the camera on the plane of x-z.  Likewise I've added a free mouse mode to let me move the mouse and fly over the terrain.

Speaking of terrain I've added a checker board to show me the X-Z plane at about -0.5 Y.

I also noticed a winding order in my Blender exporter tool, I've not fixed that in the python, just patched it in my loader and created a few more models to start building out a play space.

Technology wise I need to make the camera more usable - a full third person camera basically.  Then I would like an orbit cam, which moving in the strafe would move it around the locked object.

Then I'm going to think about texturing and lighting.

The solid coloured aesthetic is intentional though, so anything more fancy is a low priority for me.

I am feeling much more comfortable in Vulkan though; and of course enjoyed moving all the glm implementation from the first (and second passes) over this project.

That's perhaps something I've not mentioned to you before, this project as a home engine... Well I've started and restarted it a few times.  The original was in DirectX9 way back; I wrote a page about it in 2004.

Then I re-wrote that in fixed function pipeline OpenGL; that didn't go very far, indeed I received a letter to cease and desist from an IP owner for that particular project's name was known in the wider world.  That IP has moved onto yet another owner now, so best of luck to them.

I however was knocked for six and it wasn't until 2018 that I started to look at a game engine at home again, spurred on by my change of job; and I really enjoyed that first pass, but it didn't focus on the graphics side of things, it was far more about the technology such as threading, memory management, and something you may have heard of, an Entity Component System.

All those pieces remain.

But this new project is very much just about my putting features together into a renderer, indeed the application level item is called "renderDemoApplication" and that is all this is.

What might the game be?  I'm still thinking about that, but I have three strong contenders and when I've picked one, you folks will be the first to hear about it.

Home Engine - Blender Export & Model Loading

Some progress in my home engine has been had, first of all multiple geometry rendering through my fixing up and better understanding both render passes and descriptor sets.

All of this is nuts and bolts, what I want to get to; just like the DirectX 11 rendered version; is to play with 3D geometry and placing objects into a scene.

To this end my hand written geometry is no longer hacking it, and you will have seen from my raw game engine posts I did use Milkshape 3D.

Milkshape, lovely as it is to my eye, is not a modern well featured 3D suite and sadly does not let me easily plug into the geometry live within it (one can only export and perform post-processing).

To that end I delved into how one might write a Blender add-on to export your own format...

Long Story short, here's my text intermediate output from just such a plug-in written in python.

The plug-in is far from robust, I followed the lines of another open source plug in and applied my own, copying it into blender with a batch file and clearing the pycache each time I perform an edit.

But it is doing the job I initially want, and I get my own format of file output.

And indeed I can load these into my engine...

I can work on the axis for the data output and start to ensure my camera system from the main client works as expected in vulkan; since the maths here is exactly the same code I don't anticipate any issues.

This should free my mind up to think about a lighting system and to finally get back to where I was with the coloured cubes in the DirectX 11 version and ultimately onto a full scene.

I have four constant things in the world, a ground plane, a skybox and a center marker flag (showing X, Y and Z axis respectively) with a quartet of boxes in the center of the scene.  This is the test scene for the "world" loaded into the scene graph.  And it's where I want this to be this time next week perhaps.

Since progress has been much quicker now I'm past the deep dive into learning the initial set up of vulkan.

I can also appreciate much more why folks just pick up an off the shelf engine, I myself make little prototypes in Unreal Engine 4.  But this kind of denudes me of the walk through these technologies.

For the most part creating an engine like mine, which is planned to have solid shaded low poly vehicular combat, well it's a solved problem, so I'm enjoying following in a lot of well trod foot steps to better my understanding of the processing, memory, mathematics and challenges in writing a game engine.

Home Engine - Set Course for Vulkan

Over the last year I've been experimenting with writing my own home game engine, initially I spent time writing my own line rendering and then a wrapper with SDL2 all using my own mathematics library as a refresher.

Then I set up an engine framework, switched my own none-peer reviewed and frankly shaky maths for glm and started to use DirectX11. You can see a clip in my earlier blog post here.

I dabbled with other graphics interfaces, but ultimately I wanted to land on one of the two big modern interfaces, either DirectX12 or Vulkan.... And since I'm a linux guy at heart Vulkan won out. The difficulty? Well, setting up a Vulkan renderer just to render the "Hello World" triangle is over a 1000 lines of code.... And well, I wanted to write a framework as I went so I could just port this Vulkan back-end work into my abstract renderer API for my existing DirectX11 driven engine. That is my next step, but tonight, after a few hours each night this week I've finally gotten to the 3D step and I'm so excited I wanted to share with you.

So here we see I have multiple pipelines & render passes. It's creating and submitting multiple command buffers, I have integrated ImGui very roughly too.

But this is the first time I've used the uniform buffers, descriptor sets and descriptor layouts to send a uniform buffer (MVP) to the shader and get actual 3D.

I'm strongly following this online tutorial.

Though I also have the Vulkan Programming Guide official book and I'm writing my own functions as I go so the porting to the existing Home Engine API is minimal (or rather as minimal as I can get it).

One of the key pieces of tech in the base engine (driven happily by DirectX 11 when I switch to it) is a full camera fly mode system and a scenegraph rendering models.  I've also got a python driven exporter written for my own model format from Blender (and desperately need to get better with using Blender).  And I have a Python driven project generator (which calls down into CMake quite neatly).

The engine is structured into six major modules:

Base - which contains a host of utility functions, data types and tooling assistance.

Ecs - yes, I'm writing my own Entity Component System.

Renderer - The abstract renderer API which the application level creates and uses in the main game loop.

Application - Main app & game loop, I'm using SDL2 as the main interface here for input & window management in a cross platform manner too.

Physics - A basic hand written rigid body physics implementation, at the moment it really only supports rays, cubes and sphere intersection tests and I'm thinking of shopping around for an off the shelf something.

Game - Contains specific game logic, like spawning, camera controls, input mapping and uses base to provide timing.

This is all very rough and ready, it's a project to keep me interested in my craft really.

And putting Vulkan into the mix has been a real nice way to resurrect where things where, as you may gather I had the DirectX 11 and basic camera system all working in October 2021; but I've been a busy boy since then, both with work, life and moving house....

Now the new office is done and I'm building models in real life, I figured it'd be a nice time to build them in virtual spaces too.

P.S. I have no idea why some blocks are in white backgrounds, very annoying of Blogger to do that?