No title available
❣ Chile in a Photography ❣
PR's Tumblrdome
Sweet Seals For You, Always
d e v o n
dirt enthusiast
Mike Driver
Janaina Medeiros
Xuebing Du
titsay
AnasAbdin
Cosmic Funnies
No title available
Acquired Stardust
almost home
RMH
I'd rather be in outer space 🛸
let's talk about Bridgerton tea, my ask is open
Peter Solarz
🪼
seen from Ukraine
seen from Singapore
seen from Singapore
seen from United States
seen from United Arab Emirates
seen from Türkiye
seen from Malaysia
seen from United Kingdom
seen from France
seen from Ukraine
seen from Malaysia
seen from Malaysia
seen from Indonesia
seen from United States
seen from United States
seen from United States
seen from Finland
seen from France
seen from South Korea
seen from Ukraine
@sudowrestler
I'm sometimes way too good at entertaining myself
I know it's been a billion years, but this is some of what I've been up to lately. The project can be found here:
C/C++ cross-platform audio library for games. Contribute to Equivocatorrr/AzAudio development by creating an account on GitHub.
Cross-platform game development tools written in C++ - SingularityAzure/AzCore
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.
This assumes a working knowledge of matrices, and even some level of intuition for how transformations are laid out in matrix form. If anyone is interested in a more fleshed-out clarification for those less familiar, I may write a more thorough explanation of the processes described here.
Opening segment to a Tower Defense in progress.
Torch Runner
@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.
(Azure Indie) Segment 2 from AzCore Tower Defense
Hey, been a while. Yeah, I'm not dead, just been through a lot recently. Anyway, I've been busy working on all kinds of new projects, most of them with AzCore at their base.
The amount of work on AzCore itself has started to wane a bit with some smallish tweaks and bug fixes here and there.
I plan to go into some of the newer projects soon, and I plan to post more pictures than I have in the past.
So I've been keeping myself busy working on AzCore and the odd side project. Most recently I've started building a GUI application for remapping controllers in Linux, which is well on it's way, and also available on GitHub.
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.
In any case, the best course of action for the Application is to support both APIs seamlessly since actual games might use one or the other.
To itch.io!
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):
https://azure-indie.itch.io/azcore-tesseract
So after several painful hours of deciphering the encoded documentation Microsoft left behind, reading through some example implementations, and slowly piecing together the whole picture, AzCore Testing now has gamepads implemented on Windows.
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.
That was a rough day and a half, but I think the worst is behind me. Unless somehow XInput manages to be anything close to as messy as DirectInput was, but supposedly it’s nicer. We’ll see. We will see.
The AzCore Testing Branch is now how I will go about implementing new technologies into AzCore. While I’m still relatively new to how git works on a more-than-basic level, I think this might be a good way to go about things.
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.
~Cheers~
An example of a 4-Dimensional hypercube, made in a day using AzCore, (for easy use of Vulkan, vector and matrix math, and cross-platform Window I/O). AzCore is in development by Philip Haynes, and available on GitHub under a Creative Commons Attribution-ShareAlike 4.0 License. Music is "Peace in Penance" by Philip Haynes.
AzCore
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.
Until then, happy coding!
To GitHub!
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.
Anyway, it’s been a long time coming, so I’m excited to finally put it out there!
Hey. Yeah, it’s been a while. Spent a good while burned out, partially from the project, but mostly just from life in general.
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.
So, with all that out of the way, expect to hear more from me soon; just don’t hold your breath.
Highlights of the stream I forgot to mention I was doing
Tried to add twitch follower notifications but learned it couldn't be done with the Node.js api I was using. Spent the next two or so hours trying to get a more general-purpose twitch api to work. Learned I really don't like Node.js. Made some progress with the help of MerlinLeWizard but got stuck staring at some very unhelpful documentation once they left. Began implementing a basic system for switching scenes for things like objectives and game modes in my game. Got a very simplistic system working at a snail's pace. Eventually just tuckered out because I was simply too tired to be very productive.
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.
This can be done asynchronously, so you won’t really have to worry about frame stutters when using it that way.
I’m taking a short break from the main project to work on some prototypes for things I’ve been wanting to try for a while now, some of which will end up being merged into the main project afterwards.
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.
Cheers!
