The original WAV decoding library I found turned out to be pretty useless -- a lot of it was /* todo */ and the stuff that wasn't was so poorly documented as to be practically unusable. I searched around a bit and eventually found something called miniwav that looked promising. It even had mp3 and ogg cousins! And then I realized that those libraries had been written for a larger project called miniaudio that was more or less what I'd wanted to do with mossrose but better. It's as minimal-dependecy as PortAudio is, but it supports a ton more than my first pass at mossrose, including file decoding, resource caching, and even 3D spatial audio.

honey is now using miniaudio for audio.

I've done other things too! I wrote up a first-pass at assimp bindings, and they seem to work just fine. See for yourself:

That's right, you can now view Suzanne in honey!

This is still just a first pass -- it doesn't import materials, transforms, or animations right now -- but it's definitely good enough for rendering mesh data from honey. Once I'm working more on the Lua side of things and have a better sense of how I'm going to design the native honey data format I'll get the rest of that stuff implemented.

As far as basic C bindings go, that just leaves user input, cairo, and ode -- all of which existed in the pre-refactor version of honey and should (knock on wood) be pretty easy to port over. Once they're done, I'm planning on moving into a more iterative cycle of entering game jams with honey, building tools for the jam, and then refining those tools into actual components of honey itself.

1. The current development philosophy for honey

I've changed my mind about how opinionated the C layer should be. Originally, it was going to be a little opinionated; I was going to standardize function names, possibly try to standardize some argument orders, and just generally make it a little bit clean. I've since updated my thoughts to not opinionated at all. That's right, I'm now passing the C functions through as unchanged as possible!

This is for two reasons. First, the original C libraries were usually pretty well-designed and internally consistent, and even if they don't stylistically fit with each other, they do fit with themselves, and trying to minimally change everything while making it all stylistically consistent are frankly incompatible goals. Second, it means that for folks with familiarity with the underlying C libraries -- and I'm thinking most especially of OpenGL here -- working with honey should now be quite simple, because the functions and systems they're used to are still here, with the same names and (most of the time) working in the same ways.

Obviously there are some changes needed for C-to-Lua conversion, e.g. userdata instead of pointers, tables instead of arrays, et cetera. But I think these changes have been pretty minor all things considered. I showed stefonzo the most recent demo code and he was immediately struck by how similar it is to the C code it's intended to replace. Success!

I've also finally been reasonably successful in stripping out dependencies, to the point that honey can now be compiled on Windows with no dependencies installed. I believe it may still need a dependency or two on Linux, but I think that that's an acceptable level. c:

2. Textures & 3D transforms

In the last devlog I talked about hoping to get triangles rendering. Well, uh, we've definitely done that! In fact, I have vertex buffers, element buffers, and vertex array objects all working well with full shaders, textures, and basic 3D transforms and cameras. Not everything is implemented yet -- I basically just provided Lua bindings for the specific cglm functions and uniform-setters I'd need to make the demo run -- but the framework is in place to readily and easily expand it as needed, and I don't see any significant barriers to providing full bindings soon.

I've been thinking about providing the ability to load from a .zip file, like LOVE does, and that may require a slight rewrite of the texture loading. Hopefully it doesn't, especially because the next point (audio) will also require some reworking too.

3. Audio

That's right, audio!! We didn't have any audio in the pre-refactor version of honey so this is some new territory for me. I searched around a bit for a good audio library in C but I couldn't really find any cross-platform, minimal dependency libraries that I liked aside from PortAudio which is super low-level. So... I wrote a mixer library on top of PortAudio! I found a pretty neat library called plibsys which provides a ton of really neat cross-platform capabilities. I'm mostly using it for the mutexes and atomic operations, but its got me thinking about binding some of the networking stuff into honey too...

The library I wrote is called mossrose. Right now it doesn't support loading audio, just playback, but that's the next thing to work on. I've already found an MIT-licensed WAV decoder and a CC0 mp3 decoder that I plan on packaging with it. After that, I'll write some Lua bindings for it and then we should be in business.

Special thanks to Greasboi and m-dayo for helping me understand how stereo audio panning works!

I'm redesigning that system. Now it will be possible to construct vertex array objects with arbitrary attributes so that the user has complete control of which objects have or need which attributes. It should also be possible to create and load arbitrary data into the matching vertex buffers. This may well be slower than the old version, where all mesh operations happened squarely within the C layer, but because it only happens when loading, I think the increased flexibility will be a net positive.

Next week, I plan to have some actual triangles rendered to the screen! c: