In the process of upgrading to WordPress 4.5, WordPress broke itself. So I took this as an opportunity to port my blog over to Hugo. The only downside is that I no longer have comments. Not that anyone reads this or comments on anything I post anyways, so no big loss there. If anyone wants to comment on anything, you can just message me on Twitter. Since the entire site is now a static website, everything should load faster.
I’ve been very slow to actually post new content to the blog, but fear not, while I may be super slow, I do not plan on abandoning the site! Some things I plan on doing … eventually: Post more about Shibboleth’s architecture. Convert blog from WordPress to a static site using Hugo! Need to figure out what solution to use for comments. So, essentially the posts become static content and the comments are dynamic.
I feel like I haven’t said anything particularly useful in a while, so I’m going to go over the architectural design and flow of my work-in-progress game engine, Shibboleth. Application Layer Our journey begins at what I call the Application Layer, which is nothing more than what the executable the end-user runs actually does, which isn’t much. To start, let me explain the expected folder structure the executable assumes.
Been way too long since I actually posted anything here. I swear I’m not dead and I’m still working on Shibboleth! I’ve been re-factoring my graphics integration for Shibboleth, so I haven’t had much to say. I’m also working on something that I’m not quite ready to share yet, but hopefully sometime soon! Just a quick post to let the one or two people who actually read this know that I’m not dead!
It’s been a few months without any updates from me. Fear not, I have still been working on Shibboleth. Most of my work has been updates to supporting libraries more than actual engine work though. To name a few, I added schema validation to my JSON class, restructured my job pool system, and started adding in the actual graphics pipeline to the engine. I’m having to do a bit of a refactor on my graphics multithreading.
I really missed my one post a month target by a long shot this time. Two months late! I got my update system to run in stages. So now you can specify updates stages that all run independently of each other, but in order. The updates all operate on frame data that is saved and passed to each stage. This way one stage can continue generating the next frame while the other stages are doing work.
I got a little distracted these past couple months. While hashing out my camera system, I realized that I didn’t have all the support in reflection that I needed. Mainly, I didn’t support reflecting arrays. It took a hell of a long time to get it in, but I finally have it. I also got distracted from writing this post, so it’s a month later than my usual month late posts.
Well, I had a pretty uninteresting weekend on engine progress. Effectively, I haven’t made any real progress on the engine part. I mostly spent time tracking down and fixing bugs. I fixed a very egregious error in my HashMap code when removing elements. I was trying to get smart and try not to rebuild the entire HashMap when removing an element, but it was failing in certain cases. I have resorted, for now, to do the brute force HashMap rebuild methodology.
Again, nothing interesting has been happening lately on the game engine front. I’ve spent this weekend implementing the necessary classes for doing frustum culling. For those who don’t know what that is, this will allow me to figure out which objects are actually within the camera’s frustum and only render those objects. This, however, does not take occlusion into account, so I could be looking at a wall and it will still return objects that are behind the wall.
I’ve been silent for a little while, but I have been getting some work done! I ended up fixing a bunch of threading issues with the OpenGL version of my API. The problems were with sharing display lists and loading resources on worker threads. Shibboleth can now run with both Direct3D 11 and OpenGL 4.3 renderers. I’ve also implemented deferred versions of render device on both versions of the API. With these you can generate command lists on other threads and then play them back on the main thread.