Indie Dev

Here are some notes describing a general 3D transformation pipeline as typically used in 3D software and games. They helped me understand in concrete terms how 4x4 matrices are used for graphics. Maybe they'll help you too.

@flubz and I both participated in our first game jam, and let me say I couldn’t have done it without her help! I have to say, this whole experience has been a thrill, and I’m exhausted but satisfied.

The amount of work on AzCore itself has started to wane a bit with some smallish tweaks and bug fixes here and there.

Along the way I've learned a lot about the input drivers on Linux, and have come to ask myself why libevdev is considered an improvement? Like sure, pure ioctl calls aren't as pretty, but to get the same basic functionality that I have in the "legacy joystick api" I have to multiply my lines of code by at least two. This will probably even out with more advanced usage of the api, but I'm not even sure about that.

It occurred to me today that I should be distributing builds of my AzCore example projects so that the proof-of-concepts are easily accessible.

So here I’ve uploaded my Tesseract example project, and it’s available for free download:

Here's a link in case that didn't embed correctly (because tumblr):

That said, I believe I still have some work to do before it’s robust (since it appears that buttons aren’t presented uniformly with DirectInput like they are with evdev), but as far as testing with my Logitech F310 Gamepad goes, it’s all fine and dandy.

As of yesterday, I completed the baseline for Raw Input on Linux, and some of it for Windows. Currently Gamepads work on Linux via Raw Input, but getting the same functionality on Windows is going to take some more work since Gamepads and Joysticks require a separate API from keyboards and mice to get working properly on Windows.

Another project currently in the works is font file loading and parsing. The idea is to provide a quick way to render signed distance field text atlases, which, as far as I know, can’t be done using FreeType. Once this is completed to the point of usefulness, I plan to create an example project that integrates the atlas generation from the Node.js ChatBot project to get fast, dynamic, and exhaustive font support.

https://github.com/SingularityAzure/AzCore

So I’ve hinted at this project a little bit, but I haven’t actually talked much about it. So here’s the elevator pitch.

It’s a low-level framework designed to be relatively simple and easy to understand, such that developing cross-platform programs with Vulkan isn’t a massive headache.

Why did I do this? Well, basically from the several projects I’ve worked on over the years, I’ve had to develop tools to solve these low-level problems, which I’ve copied and adapted from one project to the next. AzCore is just a slight formalization of that concept, where the tools are there in source code, ready to be dropped into a project and adapted to fit the needs of that project. So on the topmost level, it’s just some of the tools from my projects.

The biggest undertaking in formalizing these tools has been the Vulkan framework. Basically the way I wrote the Vulkan renderer for my game involved a lot of structures that made it easier to interface with the Vulkan API. These are things like Descriptor Pools being automatically generated by providing them with information about the descriptors you need, which saved me tons of time and energy in developing the game. AzCore’s “vk” takes those concepts and applies them to the whole API, not just choice parts of them, and allows you to instead define your Vulkan code in the form of a tree. This preserves the model used by the Vulkan API where you tell it about your program ahead of time, rather than defining everything on-the-fly like in OpenGL and DirectX11 and below. It also significantly reduces the headache that the model generally seems to cause by reducing the necessary lines of code by a factor of ten, allowing you to make a feature-full renderer in a few hundred lines of code, rather than the several thousand it would take with raw Vulkan code.

My goal with this wasn’t so much to be an all-encompassing framework that does most of the work for you. What it’s really designed to do is give a good starting point to the kinds of people who don’t want to use an engine. In that light, it handles some low-level things, like keyboard input, in a way that gives the developer a uniform interface on all platforms, but it doesn’t make many assumptions about what the developer is actually trying to do. It’s not trying to specialize in anything.

All that said, from a pragmatic standpoint, there are some assumptions in place regarding the current usability of the framework. There are a few things that I personally haven’t needed to implement yet, and so some of those things are on the TODO list.

There are also a number of things I have little chance of developing myself, such as a Mac port, since I don’t currently and probably will never own a Mac. Also Apple is deliberately dropping Vulkan support, the bastards. That said, the nature of the project being open-source means that someone else is welcome to implement the same functionality for Mac, and I’d be happy to pull that work into the main project.

As for the available examples, I plan to add many more advanced ones to showcase the power of what I’ve cobbled together over the years. Also, while the Vulkan framework is currently capable of handling somewhat simpler workloads, things like compute pipelines, complicated render passes (ones with inter-subpass dependencies), and multi-view rendering are currently on the top of the TODO list. But let’s be honest, if you’re just learning Vulkan you probably won’t need any of that.

So there’s a quick and dirty explanation of what AzCore is all about. Now that it’s reached this stage, I’m almost ready to work it back into the game. Look forward to more updates on that in the future.

https://github.com/SingularityAzure/AzCore

AzCore is now publicly available on GitHub under a Creative Commons Attribution-ShareAlike 4.0 International License.

I’ve finally taken the steps necessary to make my tools somewhat portable, and with that push, I’ve decided to put them up publicly. Of course, more steps can and probably will be eventually taken to reduce the work necessary to use them. As of right now these tools are configured to build on Linux, and Linux only, with the ability to cross-compile from Linux to Windows because that is how I work. Should anyone desire to make a setup that compiles on Windows, I will consider adding that into the project proper, but until that happens, developers on Windows are on their own.

Anyways, while I haven’t been posting much on here, I haven’t stopped working on the project entirely. In fact, I’ve started doing something I’ve wanted to do for a while now, and that’s to rewrite the renderer now that I actually understand how Vulkan works in the context of games with somewhat advanced graphics.

With that idea in mind, I’ve found the best way to achieve my goals is to write a bit of a utility layer, kind of like what I already had in place, but more extensive. The idea is that I will be able to define the shape and structure of the many moving parts of Vulkan at a somewhat higher level such that they manage most aspects of their state internally. If this winds up working as I expect, it should streamline any and all development using Vulkan by dramatically reducing the lines of code necessary to write a program with it, while also inherently following the many rules of Vulkan such that you don’t have to think about all of them all of the time.

The asynchronous nature of Vulkan still leaves a good amount of wiggle room for user error, so the utilities I’m writing aren’t necessarily there to replace a working knowledge of the API, but rather to reinforce it.

Anyway, I’m calling this new project “AzCore” and I’m considering sharing the source on GitHub once it’s usable under an Open-Source license. The first thing I did with AzCore was to take all of the cross-platform window and input code I’ve been working on for the game and formalize it a little bit such that it can be easily integrated into other projects, or used as a basis for new projects. This currently supports Linux and Windows. I don’t have a Mac to develop with, so I can’t really write the code for Mac (though you’re free to do so if you wish), but I’m probably going to port it to Android eventually (not a priority ATM).

Alongside the Vulkan tools, the Windowing and Input, I’m also releasing a good amount of other utilities I’ve put together for my game and a couple other projects. This should include a barebones vector math library, font parsing/atlas-generating tools, my xml tools, and a number of niche memory-management primitives.

Besides all of that, I’ve not completely given up on my Azure Audio project. I just need to replace the incredibly buggy PortAudio library it uses for hardware interface. So if that comes to fruition, I might integrate that with AzCore as well. We’ll see how the wind blows.

After a few days work, I can now load in font files, pack them into a 2D atlas, render them as signed distance fields, and dynamically load in any character not initially expected to be encountered at the start of the program.

For example, the default atlas only loads in the ASCII standard characters, and all of the Japanese characters are loaded into a special dynamic atlas that gets populated based on the string it wants to render.

My reasons for doing this are twofold: One, I’ve been working on this project for a while now, and it’s healthy to take short breaks from it and gain some new perspectives by trying something completely different for a while. Two, some of my more recent inspiration has arisen from messing with Node.js to make a twitch bot, and integrating with twitch was so much easier than I expected, so I wanted to see if I could get something neat going with that.

So naturally I started making a twitch overlay for Linux with all the bells and whistles. This whole project thus far has been kind of a rollercoaster, as OBS didn’t originally support capturing windows with transparency. How did I get around this? Why, I modified the source to fix the compatibility issues of course! Gotta give a little back to the open-source community every once in a while.

So now OBS supports windows with transparency (at least locally; the pull request is still pending), and that makes capturing the overlay pretty much perfect; better than is even possible in Windows.

Well, I had been kinda tired of relying on two premade texture atlases for rendering text in my game, so for the overlay I figured I might as well implement a font-face loader that can pack all the glyphs nicely on the fly rather than always relying on premade textures. That went pretty well. The only step left as far as that goes is converting the glyphs into signed distance fields, but I figured packing them would have been the hard part, and that’s all out of the way, so it should be smooth sailing from there.

The other thing to consider for font faces would be any potential characters not initially included in the primary atlas, since for Chinese, Japanese, and Korean languages, the number of glyphs can be in the several thousands. Some kind of system to load glyphs into a secondary atlas based on their occurrence might be in order. This one could most likely be updated on the fly fairly easily and without much fuss. That way, you could preload the thousand or so most common glyphs and then should you come across something unique, like you might get in a name, just add it to the secondary atlas. Easy as that.

Anyway, that’s what I’ve been working on for the past week or so. I’m pretty excited about a lot of it, especially since it seems a good portion of it will be easy to port into my main project.