All Activity

Hey, everyone! As you may have noticed, this took quite a bit longer than we expected, for a variety of reasons. We'll get into some of that later - for now, we've got some pretty big changes and updates to share! Renderer Switch (the sequel) You may recall in our previous announcement that a large focus was placed on switching to Ogre (specifically Ogre-NEXT). At the time - again, keeping in mind that so far, this is still a one-man show - I felt that writing shaders from the ground up was a bit too far outside of my skillset, and given my general challenges with math stuff in the first place, I wanted something that had native support for materials and PBR and such. So it may come as a bit of a surprise that, after all of that time - we're now switching away from Ogre entirely, and going with a fully custom renderer built on top of, once again, bgfx. This decision was not taken lightly and came as a result of a number of things all converging together that tipped the scales. Why switch? First and foremost, there was a bit of ongoing issues that kept cropping up with Ogre, mainly crashes here and there, as well as a persistent crash during shutdown. These are almost certainly something that I've done wrong and part of an issue of how I'm using it - but that pretty cleanly takes us to the next issue. Given that we wanted to have our own classes and objects in many cases that abstract Ogre away - this resulted in a lot of cases where there was always this additional layer between the game engine and Ogre. For instance, any object in 3D world space inherits from BlamWorldObject, and each one would reference an Ogre::SceneNode - with attached meshes or lights or whatever else depending on the type of object. This works, but also due to how Ogre itself is built, presented some challenges of its own too. One of our goals is to make as much of the engine as thread-safe as possible, the goal being that the engine won't thread-lock or crash when manipulating objects or running code from various threads, allowing developers to take advantage of multi-threading as much as they see fit, and ensuring the engine itself doesn't make this process a painful one. Ogre is not designed as such - and so often there were many cases where we just had to build these things in ourselves. Abstracting away object positions/rotations/scales behind Get/Set methods is one example - as if you tried to modify an Ogre SceneNode transform from anywhere other than the render thread (or even if you did so later in the render process), you'd get an assertion failure or other error. Another big issue came up when we started exploring 2D rendering - we wanted to implement support for tilemaps, which we wanted to be able to support multiple texture sources. Trouble is, this is where Ogre's high-level material system actually becomes a hindrance. In bgfx, this process would be as simple as a single function call before submitting the geometry. Ogre makes it so that, seemingly, we'd need to create an entirely new HLMS specifically for this use case. Custom shaders suffer from a similar problem too - we were having to modify Ogre to have better error handling for invalid shaders, the idea being that the engine shouldn't crash if a shader is broken, it should just warn or fall back to something else - which would at a minimum be required for having a proper shader editor with a preview, as if you messed something up at any point - the entire engine would go down. These issues gradually crept up over time, and it eventually reached a point where I decided to once again explore the possibility of building a new renderer with bgfx. Something where I can avoid a lot of this extra complexity, and something where even if it wasn't perfect, it'd be good enough that it could be iterated on and improved over time. AI (non)-Slop The last thing that fell into place that ultimately enabled this plan - is the ongoing progression of AI/LLMs. This may or may not be a bit controversial depending on your stance - but given the capability of some frontier models (particularly Claude in our case, especially Opus 5.5 - though we started this back when Opus 4.7 was the latest version), we've found that it's been extremely capable and competent. It may also be worth clarifying - while I will often write "we" out of habit and to refer to the studio, in reality - "we" is really just me. There are no other developers on the project (though we'd love to have some if you've got some time!) - and I don't exactly have the budget to hire people properly, nor the free time I had a few years back. And in areas like this - where it's very math-heavy stuff that I just have a tough time with - I felt the best move ultimately was a purpose-built renderer designed for the engine itself, that can be iterated upon down the line, rather than a heavy library that is mostly out of my hands. The time savings alone are, for me, one of the biggest draws to these kinds of tools. It took probably ~6 months or so of off-and-on work, with me working ~48hrs a week otherwise to keep myself afloat, and in that time I was able to, using Claude, build a renderer from the ground up on top of bgfx that, while imperfect and isn't quite as performant as I want it to be, is already outperforming Ogre in some tests I've done - and is something that is small enough that it can be iterated on. And if I'm being honest - after 10 years since the engine's C++ project was created on my old computer, at the rate things were going - there was no world in which I was going to be able to achieve this on my own in any reasonable timeframe. I'll also add - this renderer was not vibe-coded, at least not in the typical sense. A lot of code was written and authored solely by AI, but it was done so following the existing code style guidelines and organized/structured how I would've done it myself (in terms of what classes/types are named, how stuff is broken up across files, etc). It was a much more involved process than the stereotypical "hey claude write me a PBR renderer" - this has been thoroughly tested as much as I can as one person, and has been designed around an engine and feature set that is entirely my own. Going forward, I'll likely continue leveraging these AI tools in order to hopefully have development be a bit quicker than it has been thus far. We hopefully also won't be doing any major changes to the engine's tech stack anytime soon - since now its on a foundation that exists within the engine itself. We will however be continuing to flag any new classes, methods, or functions that are AI-written with an @author attribute, which is visible in both the code itself as well as Doxygen. If you're one of the folks who are disappointed reading this, due to finding deep moral issues with AI stuff - I do understand - especially given that the most visible cases of AI are either intrusive or of poor quality. I would however encourage you to reconsider, particularly for cases like this - a lone developer with a fairly tremendous scale of a project, using such tools to essentially make up for the lack of resources. The alternative in this case wasn't going to be hiring a developer - it was going to be me, independently continuing this project on my own free time, a resource which has only become more scarce in the past few years. I'll also make it clear that we will never be using AI for art or visual assets - those will continue to be either created by me or will be acquired from some 3rd-party site (either an asset store, online web source, or a marketplace like Fiverr, or something of the sort). When it comes to the programming side of things, however - we don't expect to stop using such tools. We'll be using them more conservatively than some - we aren't looking to create the AI Slop Game Engine®™© - we're just looking to build Blamite, but at a rate where it might be usable for real game development within the next decade . If even that is a deal-breaker for you - then fair enough - in that case I'd highly encourage you to check out Godot, as I've found it quite capable and dead simple to use - and it's free and open-source as a nice bonus. The New Renderer As mentioned before, our new renderer is built from the ground up on top of bgfx. Right now, we're primarily supporting OpenGL, but we're already working on getting some refinements in place to ensure that D3D11 and Vulkan are up and running as well. We did consider making this more of a priority for this release, but we felt that getting a release and a development update out first was a bit more important given just how long it's been. The new renderer is a proper deferred renderer, with Forward, GBuffer, Lighting, Postprocess, Shadow, SSAO, and UI passes as of now. We'll likely be continuing to expand things over time as well. Either way - let's go a bit more into some of the features it has! PBR (Deferred Shading + Forward Pass) and Instancing First and foremost - the backbone is, as we've mentioned earlier, a deferred renderer. Its implementation of PBR has many of the same features as Ogre (though not all as of yet). The existing material tags are still used and behave in much the same way, though a handful of fields are no longer used by bgfx. Most of these fields will likely be removed entirely, as they were setup based on the various properties of Ogre's PBS HLMS datablocks. Instead of the datablock system that Ogre uses, this renderer instead is a bit more simplistic - material parameters are "baked" when first loaded and/or when reloaded, and get used that way - which avoids repeating texture or tag lookups. Additionally, multiple instances of a mesh are batched together and submitted in one draw call, massively improving performance when drawing many of the same object. This is also a use case where we actually achieve better performance than the equivalent with Ogre. For transparent materials, a Forward pass is also implemented. This is the newest and roughest addition - it functions quite well, but performs poorly - though this is something we'll be working to rectify as we continue development. SSAO (Screen Space Ambient Occlusion) Another fairly immediately obvious feature that we've added in, is SSAO - which all on its own helps improve visual quality. You can compare a couple screenshots below with it turned off and on: Fog Another feature now supported is a simple one - fog. Available in Linear, Exponential, and Exponential Squared varieties (pictured is linear and exponential squared, with different options): Surface Shaders (Custom Shaders) A fairly significant introduction is the surface shader system. This is essentially equivalent to how other engines (with Godot being a fairly close example) handle custom shaders. These surface shaders allow for vertex and fragment shaders to be written which run inside the deferred pipeline. Truly custom shader programs are partially supported too - but will initially be limited to the forward pass (though we hope to see if we can change this later on) and are intended primarily for advanced use cases. Other New Features Despite the renderer being the star of the show - it isn't the only change we've made since our last update, far from it. Some of the big highlights include (but are not limited to): Faster scenario loading - There was actually a leftover artificial delay between load stages, forcing scenarios to take longer to load for no actual reason Prefabs - These work essentially the same as you'd expect them to in Unity - they're collections of objects which can be created and then later reused as a single standalone object Project Tag Classes - The engine now properly separates built-in tag classes and project-specific tag classes automatically, and will automatically ensure tag classes are registered in the engine - meaning you can simply author them in Guerilla, save and export, and get to using them right away So... why did this take almost 3 years? A fair question - and with a pretty wide range of answers. First and foremost, I had some personal life events come up starting in 2023 - mainly that my financial situation got a lot more dire, and I had to get some proper employment after taking arguably a bit too long of time being unemployed. This was a bit of added stress for one, and also of course meant I didn't just have an endless amount of free time to work on things. This has been ongoing of course through the present, and there really isn't gonna be much room for that to change anytime soon. Additionally, fairly shortly after the last development update, we started development on Sandbox - which is a 2D top-down sandbox project, as the name implies - which ended up with a substantial amount of development time being spent towards it as well. And of course - we have been continuing to work with Ogre during this time as well, only relatively recently deciding that it was time to make the switch. What's next? This is the real exciting part. First and foremost - we've released a new build of the engine today. Similar to how last time, where we left in the legacy D3D11 and bgfx renderers in place as an option, for this new release, the Ogre renderer has been left in as well. The first thing we're doing after this release is completely removing Ogre from the engine - leaving only our new renderer. From there, we'll be continuing to iterate and make some additions and refinements to 3D and 2D. We want to add a bit more visual effects, refine some of the existing systems (such as UI), and likely explore other features that Ogre had but that we didn't use yet - such as decals, particles, and terrain. On the 2D side, we'll be working on refining tilemaps, getting support for other 2D objects like sprites, as well as working on expanding support for UI controls and having some good starter widgets (like more layout boxes, buttons, panels, etc). On the editor side - it's still pretty far from being a fully-featured editor that you could actually use effectively. It can work for some stuff, but its very clunky in some areas and is nowhere near game-ready - and so this too will be an area of focus. One other thing that we've also decided on with this, that sort of started this whole renderer migration again - is Sandbox. Originally, our plan was to build it using Godot - as we felt that this would be the easiest/fastest approach to get a game developed and released within a good timeframe. At the time, we felt we could get from start to finish in a year or so (). However, we ran into some of the same threading and performance issues there as well. In particular we wanted to have a multi-threaded chunk generator - but turns out Godot doesn't really let you modify tilemaps from other threads, so this ended up killing off that idea. And ultimately the solution we decided on was to actually start fresh and build Sandbox in Blamite. This gives us a chance to fix some of these issues, allows us to use C++ for scripting (as that's currently all we have - though we'll be adding C# in later), allows us to maybe clean some of the codebase up and do things a bit better than we did last time in that regard, and - of course - gives us a real project in the engine that we can start building fairly soon. We've got some other ideas too for 3D projects that we want to develop concurrently - but those are a bit too rough for us to commit to at this time (and realistically is gonna be a lot further out). To close out, we've provided a link at the bottom of this post to the Blamite gallery page, which contains a bunch of screenshots that we've captured during the engine development. All of the ones recently that show the warehouse environment are ones taken with our new renderer (barring ones where things look very broken - those would've been tests to see how ogre dealt with the same scenario), and gives you an idea of what's possible today, right now. We absolutely plan to get some fancier stuff in the future, with some real outdoor environments - but there's a lot of work yet to be done for such environments to be achievable, so we started with this. At some point we do hope to release the tags for this environment as well - however it relies heavily on Quixel assets and materials which we can't just freely redistribute. We're looking to see what we can do to work around this (maybe releasing the non-asset tags, plus a script that can take all the zips from Quixel and extract them to the right spots and import them into the engine, allowing users who own those assets to grab them and get everything back). When we do so, we'll either leave a comment on this post or make a separate announcement somewhere. For now, though, that's all we've got! Be sure to check out the gallery, as well as the link to the latest engine build to check it out for yourself! Blamite Gallery Latest Development Build