May 2024 Progress Update

Here we go again.

We’ve been working on Focal Alpha’s 1.20.4 update for too long now, and while we have made some progress, we are sadly not at the end of the road yet. On a happier note however, we did push a small update to Focal for 1.20.1 that resolves a crashing issue with World Borders that was reported to us, and we had mentioned in a previous blog.

Work on Focal VK progressed steadily this month as well, with dot’s time being split between Focal Alpha’s 1.20.4 update and Focal VK, and Jake bouncing between Focal VK and Continuum 2.1 Beta. We do wish we had more developers that could be devoted to a single project, but having a project to jump over to when you hit a wall with another can help with motivation and morale. It’s also preferable to potentially wasting days being stun locked on a single issue in our opinion. A small upside to juggling this many projects with such a small team at the very least.

Speaking of Continuum 2.1 Beta, we had prepared another small update for that this month, but discovered a issue that we could not properly fix before update time rolled around. Last months additions/fixes will be rolled into next months update.

That’s a fairly high level overview of what we got up to in May, but for those of you who want more raw, technical details, we’ve once again got some summaries from each of our Focal / Shader devs below!

First, dotModded:

Most of my work this month has been working on the 1.20.4 update. I have finally made some progress diagnosing the issue.

Forge has changed how their mod loading mechanism works entirely between 1.20.1 and 1.20.4. Java’s module system is not recognizing which packages belong to focal engine. This results in certain classes using the wrong class loader, making essential library classes unavailable. We need to further dig into this issue and potentially make a pull request as this may be a bug with the latest version of Forge.

I have also been hard at work with initialization and initial configuration state of Focal VK, setting up the project to be launched from Minecraft. This includes the creation of the windowless gl state, window(s), the focal engine threads, and so on.

Sorry for the lack of progress, the update for 1.20.4 had me stumped for quite a while. Hopefully now we can make actual headway on getting this resolved and getting the update out.

And now, Jakemichie:

I’ve mostly been a bit all over the place recently, jumping back and forth between 2.1 updates and bug fixes, and working on different aspects of Focal VK. Quickly regarding the recent banner fix for 2.1, I did manage to fix banners glowing but the fix seems to have caused issues elsewhere with specular on certain metal blocks. I’ve had to change the encoding scheme for our gbuffers a bit to fix banners glowing, but in doing so the new encoding scheme seems to have produced a strange blocky pattern on the metallic parts of ores and raw metal blocks. Tracking down the exact cause has been tricky since I have to change so much code to switch to the new encoding scheme, to the point where I’ve had to redo the switch to the new encoding scheme three times now to try to narrow down the problem. So far I haven’t had any luck, so I’ve had to put the banner fix on the backburner until we find the cause of this new issue.

Additionally, I’ve been playing around with custom lava, but that didn’t pan out the way I wanted. I would have liked lava that changes based on how fast the flow is, with it being cooler and more solid at lower speeds, and hotter and more liquid at higher speeds. Unfortunately the seams along block edges tend to make that look really bad. So there is a good chance that this never makes it into an early access build of 2.1, unless we find a far better way of doing it.

Here’s a short clip of that custom lava shader that will hopefully convey what I mean. Please keep in mind, this was an experimental, work in progress test to get a better idea of how things would behave and look…and is why it will probably not be something we move forward with, at least not for Continuum 2.1.

Beyond 2.1, I’ve been working on a few different things for Focal VK. The first thing I’ve been working on is figuring out how to implement Lua and integrate it with the rest of the engine. We’d ideally like Lua to be multithreaded so that we can run Lua code in parallel across multiple threads, but this is harder than it seems as Lua is fundamentally single threaded in design. The approach that I’ve settled on is to have multiple instances of Lua running in parallel, with each instance belonging to a different type: executed serially but with global state, or executed in parallel but without global state. We’ll have a single serial instance and a pool of parallel instances, and we’ll allow threads to acquire the first free instance of the corresponding type based on an atomic bitfield representing which instances are busy and which are free. Lua scripts and callbacks can specify the type of instance they want to be executed by, which lets us safely multithread Lua code execution when global state isn’t being used, while still allowing for global state to be used by opting out of multithreading.

The second thing I’ve been working on is redesigning the render graph. I wasn’t entirely happy with the first redesign that I talked about a few months ago, so I’ve since been figuring out how to improve it and I think I’ve settled on a decent design. Most of my time here was actually spent looking at how the rest of the industry implemented render graphs, which turned out to be mostly useless for our situation as the rest of the industry seems to have taken a very object-oriented approach, which Lua sucks at (it can do it, but it’s real ugly). I did manage to find something that was useful, and funnily enough that was AMD’s Render Pipeline Shaders. In short, RPS is a middleware that lets you build purely code-driven render graphs using a custom domain-specific language that looks eerily similar to HLSL (the shading language for DirectX). You’re basically given an entrypoint function that provides the backbuffer target (the render target that you need to write to, to get something to display on the screen), and you define the structure of the render graph by “calling” into passes as if they were regular functions, passing around resources like textures, render targets and buffers as regular variables. It doesn’t map 1:1 with what we need, but the overall structure is pretty much perfect, so we’ve decided to loosely base our new render graph design on RPS. I’m not going to provide any details regarding the new render graph design since I want a working prototype for that (I’ve pretty much just started prototyping it), but looking at RPS should give a little bit of an idea about what it’ll look like.

The last thing I’ve been working on for Focal VK is the tracked value system. Well, I haven’t specifically been working on it, but I have thought of a couple pretty major changes to it that should improve it. The main change is how tracked values are registered and how memory is allocated for them. The current design has you register all tracked values first, then it allocates a single block of memory that stores all tracked values. This is good as it keeps allocations low and lets the system really focus on compactness when allocating memory, but it’s also bad as it makes the system effectively static and prevents you from creating references to tracked values until *all* tracked values have been registered. To fix both of these, I’m thinking of swapping to a dynamic allocation scheme, where fixed size blocks of memory are allocated in a free list fashion, then tracked values are mapped into blocks using a bump allocator (maybe swapping to a free list or stack allocator, if we ever need to unregister tracked values and deallocate their memory). Additionally, I’m thinking of reworking how types are handled in the tracked value system, and I’m thinking of adding groups/namespaces to unify multiple tracked values under a single tracked value group/namespace.