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?

Home Engine - Loading PNG Textures into DirectX11 with SDL2

ANYONE Interested in my sharing the code to do this?  Leave a comment, 10 comments and I'll blog it.

I'm using SDL2 as the background framework for providing cross platform input and window handling, but I'm writing my own renderers for various platforms (DirectX11, 12, OpenGL and Vulkan).

All of them support coloured shape and line renderering to one extent or another, so I decided to take the leap into texture mapping.

First of all I put in all the framework to represent textures in my engine in a cross platform manner, and for ease I decided to use SDL2_Image to load my pixel data.  And I started with a simple PNG file I created in MSPaint....

Immediately I ran into issues, PNG is RGBA, the png I created had a transparent background as far as I knew it should all work.  I swapped to RAW pixels and I was getting 4 bytes per pixel, it was only after a bunch of reading and then stepping into the SDL_Surface format did I realise the data might be whatever format but the surface was clearly 3 bytes per pixel.  And funky things were happening.

My assumption that MSPaint was outputting 4 bytes per pixel was just wrong, instead it's 3 bytes, RGB.  And there's no matching DXGI_FORMAT for just RGB - least none I could spot.

A quick reexport in GIMP setting the explicit pixel format to 8bpc RGBA, which then of course just worked....

Therefore, it's official, using an SDL2_Image load of a PNG as your DirectX11 texture is perfectly possible.

And for me, this reduces the need to include yet another library (other than SDL) to handle image loading.

----

Not even sure how, but this older video got attached to this post, which is about "SuperSampling".... but really just changing the renderer to window resolutions...

Home Engine - Lines and Camera Interaction

 Yes, yes, it has been a while; both here and on the YouTube channel, I've just been very busy okay?... Okay.  Friends?... Friends.

So what have I been up to in code?... Well today I added line rendering to my home engine, this is still using the underlying "Triangle" raw data, so I have to always have a cleanly divisible by 3 (for the sides of a triangle) number of indices in the data, but otherwise it just seamlessly integrated.

Its using "LineList" as the underlying primitive type, which maps to the D3D11 type under.

I also noticed that these lines from 0, 0, 0 to 1, 0, 0 and 0, 1, 0 and 0, 0, 1 respectively are "backwards", that is my unbeknownst to me at some point my camera has started to spawn around in front of there my scene objects are, so I'm looking back along the Z axis not "up" along it... Am I making sense?

I also improved the camera some by linking the rotation of the camera to the mouse, which makes it super intuitive.

The failed part of the work this last month was an effort to update both the Vulkan and the OpenGL renderer implementation.  This was an utter failure, the simple reason being that I've gone too long with my limited knowledge with DirectX.  I'm sure the "port" to DirectX12 will be easier, but yeah, I've already gotten the other API's so far from my implementation (abstract base classes) that it's quite alien to return to them.

I'll circle back on that, maybe break down the API's with failed/broken builds until I can slowly etch away at the challenge.