Overhauling the UI code for the nth time. I made both the API and the code behind it simpler and added some more widgets. This won’t be the last time I’ll need to overhaul it, but I think I’m getting close. Next, I’m going to update my 3D UI code.

Overhauling the UI code for the nth time. I made both the API and the code behind it simpler and added some more widgets. This won’t be the last time I’ll need to overhaul it, but I think I’m getting close. Next, I’m going to update my 3D UI code.

Still working, just neglected this blog. I put game 1 on the backburner and put a lot of time into game 2. Recently, I implemented geometry mip/clip maps, whatever they are called. A while ago, I implemented this version from a paper in GPU Gems 2 (paper). I found the paper to be vague, convoluted, and lacking detail. For some reason, I bashed my head against the wall with the image compression and weird geometry stuff. My new version is 50x simpler, and I imagine it’s good enough for most use cases.

I have been very busy, not just with the game(s), in the past weeks. I made an actual “game” client. It’s an infinite deathmatch mode. And I actually played it over the World Wide Web! I tested, fixed, and added functionality for my map creation tool exporting and importing to the client. This made me realize a number of flaws and limitations in my gui code so I’ve gone off on tangent remaking that. At the same time, I’ve started working on the visuals for my other game. This is just a message for the future. To let everyone know I haven’t stopped or given up, and I never will!!!!!!!

Just posting for records sake. Nothing new to me, just a re-implementation. Been too busy. I did find out about https://www.mixamo.com, which is pretty cool and I’m probably gonna use it.

I am currently restructuring my entire codebase, which is likely the most challenging and open-ended problem I’ve encountered so far. I haven’t found much reliable information on how to approach this task, probably because it’s a very general problem, unlike specific topics like rendering techniques, which have many decent papers and articles. I also find that popular concepts, such as Clean Code, don’t feel intuitively sound to me. The best resource I’ve found is episode 26 of Casey Muratori’s Handmade Hero, titled “Introduction to Game Architecture.” After watching it, I believe I have a solid starting point.
I’ve never shied away from large functions, unlike many supposed developers. A significant portion of my code resides in main.c, and I follow the rule that if a method is used in only one place, it shouldn’t be turned into a reusable function. Adhering to a few simple rules has allowed me to implement features aggressively and made it easier to identify errors. If I were developing a single-player game, I would likely continue down this path. However, the challenge I face—and I hope I’m not creating it myself—stems from the fact that I’m building three programs: a client, a server, and a map editor. Technically, the server is a thread launched by the client, but that’s just semantics. Essentially, I have rendering, physics, and gameplay functions shared across all three programs. I’m starting by identifying the data structures and functions needed by all three, while also splitting them across more files and reevaluating the hierarchies to make them more logical (I hope).
This restructuring may keep me busy for a while. My goal is to have a working “deathmatch” mode as soon as possible. I already have all the necessary code written and tested from previous work; I just need to organize it better, this time.
I have implemented skeletal animation several times before. I just added it to the current version of the engine, which has a different lighting and shadow system setup. I sculpted, retopologized, rigged and animated the character using ZBrush and Blender. I also baked a normal map from the high to low poly mesh. The normal baking process is irritating because I have never been able to get a clean result.

I have implemented the shadow maps as mentioned in the previous post (https://coder187.com/2025/05/15/shadow-maps-and-area-lights/). The below image also has some radiosity baked in.

I started using dynamic area lights for the first time. They look better, and I think they make more sense than point/spot lights when joined with other lighting methods e.g. radiosity, shadows. At the very least they “should” be more inline with the goals of my current project.
For shadow maps, I am rendering them all to a large texture. I plan on storing all the light data in a single UBO or SSBO and using uniform integers to reference into those arrays. I am limiting each face to be affected by no more than 4 lights (might be temporary). So each face could need up to four light matrices passed as uniforms to the shader. I could also store those matrices in the UBO/SSBO. I am on the fence about that. Its not a lot of memory in the grand scheme though it still irks me. I haven’t done any performance checks, but my gut tells me it will be faster to just generate those on the fly on the CPU and pass as uniform variables.
I have implemented the shadow map rendering. Once I have the actual shadow rendering I will post pictures.
First post test. Screenshot of current engine.

Welcome to WordPress! This is your first post. Edit or delete it to take the first step in your blogging journey.