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 - 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?

WarThunder - OpenGL Performance Discussed

In the final of my series regarding WarThunder this week, I've taken a look at the performance of the OpenGL rendering options.

I've tried this on two machines, with different graphics cards, but very similar specifications otherwise, the two machines are:

Core i7 - 950 - 3.07Ghz

16GB 1600Mhz DDR3 RAM

NVidia GeForce 260 GTX 896MB DDR3

Core i7 - 3770 - 3.01Ghz

8GB 1600Mhz DDR3 RAM

Nvidia GeForce 540 2GB DDR5

Clearly one machine has the superior graphics performance on DirectX mode, yes the 540 out does the 260, just... Though my 260 is a really good superclocked edition, so much so its proving hard to find an economical replacement (pushing me to have to buy a 770 GTX just to see a significant improvement).

Most all the screen shots you see of WarThunder on this blog come from the machine with the 260 in it as well.

But so far all the screen shots have been from the Direct3D renderer.

Now, however I'm testing the OpenGL renderer, the option is listed as Test and I've also tried to collaborate my observations with other players... My overall impression is:

Half the FPS, if I got 60fps in a situation in a plane in Direct3D, I'd get 30 in the near same situation in OpenGL.  This is a rough and ready measurement taken by eye from the FPS reading given on screen in the client.

I've purposefully NOT recorded my game play, I've not run other programs nor over reached things - that is I've not thrown clouds of AI aircraft into formation within a custom battle and flown through them.  I've stuck to playing the regular game in the regular way.

Lets take a look at some screen shots:

It looks the same, I've not noticed any surface level differences, the game looks just as good.

Only when one scrutinizes things do you find the differences, if we jump into a cockpit and look around, we can see where in Direct3D we'd get smooth textures things can look quite odd:

This is the seat over my pilot's left shoulder in the Fw190 A1, as you can see there's this square stippling going on, also along the window rail you can see a darker indication that is actually a shadow from the wind shield surround.

This isn't the only odd thing noted, in the 540 card, not on the 260, I took the Fw190 into a twilight flight.  You can change this yourself in your settings under the Graphics options you need to select the Texture type of "Night as Day" (or something like that)...

When I flew the plane out on the 540 GTX, I saw this strange halow effect around the periphery:

The effect persisted against the clouds, from any angle, or against the ground.  But it did not show against clear sky.

Switching back to Direct3D no such halow was present on either card's output.

Performance wise I've already mentioned the lower frame rate, however, at one point during a pursuit in Historical battle in the Me410 I took out an enemy aircraft, with the explosion close I suddenly had a frame rate reduction down to 2FPS.  Literally slide show mode...

I used a little back stick to bring my nose up and came through it, but I'd moved around 1km before the frame rate returned to above 20 and allowed me to have some semblance of control.

I checked my logging, there was no hard drive activity, no appreciable network lag, no dropped packets, I could type into the client and ask "Anyone else getting lag", which was a reply of "nope" from a fair few players.  Yet I was at 2FPS 50 meters off of the hard deck struggling.

The optimisation of the Direct3D code being used by Gaijin is really good, they get performance out of my rigs other less intensive, less pretty, games get... So perhaps we can chalk this massive red blot on the performance of the OpenGL implementation to a lack of development/optimisation and of course the code being "Test".

But, one would assume the Mac client is already using OpenGL, are any Mac players out there able to share their thoughts?

Either way it looks promising that OpenGL does work, and this of course leaves us thinking about Linux/SteamOS.

Minecraft - Ordeal #4

I spent a lot of time painting the man lab today, yes those plastered walls had aired enough in their gleaming white, so there's now a feature all in a chocolate sort of colour.  And with pay-day being Thursday, I'm going to get some nice finishing touches.

I also fitted a new light in here, so that's lovely too.

Game wise I spent the day painting and not playing, but I did have Youtube playing, and from my list of "watch later" items I found a load of Minecraft items, so tonight with an hour to spare I fired up the old minecraft, and set about a new storage area, with a simple water feed bringing items from the surface down to it for me...

Deep below I also spent the last of the prepared glass shoring up the lava pool I'm undermining for diamonds.

And that was that.

One thing I did programming wise was find a bunch of my old DirectX 9 interface books... Now, I do wonder whether leveraging DirectX9 is a good option in a game today, to get all those low powered notebooks and older PC's out there all jogging along.

I'm still fascinated by OpenGL of course, for its cross platform ability, but I do wonder whether the likes of SDL or Ogre3D using interfaces should be what I look at.  Though of course one doesn't want to reinvent the wheel...