I have ported @sebaaltonen.bsky.social OffsetAllocator C++ library to single C header lib: github.com/septag/Offse...

It doesn't use any memory allocation by itself and can be compiled with both C11 and C++20 (designated initializers) compilers.

I couldn't work much on my hobby projects since I switched jobs couple of months ago. But it's been some time that I'm back to it.
All around updates for the Junkyard. Initiated a renderer. Forward+ CS light culling. Shadow Maps. MSAA and alpha-to-coverage support. I want it very simple for now.

The blog post about the upcoming experimental sokol-gfx Vulkan backend is up:

floooh.github.io/2025/12/01/s...

(as always I'll need to do a couple more edits to fix typos and repetitions but first I'll need some food intake)

The best kind of apps, are system/device configuration web apps 🤌

My hobby engine's asset manager design document: septag.dev/blog/posts/j...
Folks who want to create their own async/hot-reload asset system, might find this useful as well.

I was interviewed on the Wookash Podcast. I talk about my career, programming, and how I created 10x. Enjoy!
youtu.be/1sdjQ7uTziw

Keeping those compile times lean and healthy :)

Nice! With the new improved Vulkan backend, separate transfer queue and batch upload submission, the performance of this drastically improved. Now for 1.4GB of unbaked asset data, it takes 1.5 secs.
For baked assets (loaded from cache), it takes 270ms (5.2 GB/s). Very close to my SSD drive speed.

After 6-7 yrs of wanting to learn a modern graphics API, I finally managed to put enough time into learning Vulkan. I think I finally got comfortable with it so that validation errors don't freak me out and I usually have a good idea what's going on. (1/5)

Asset manager test. First working implementation. It loads stuff in chunks. so here, each chunk is around 60MB of data (texture+model). It's pretty much a snap (~30-40ms for each chunk).
In total, 1.4 GB of asset data loads in 700 ms. if not baked, then baking all 512 assets takes 2.2 secs.

having a good asset system is so important because it provides the "well" from which all other engine subsystems "drink" their data. any shit factor is multiplied by the number of things that deal with the asset system, and that number is roughly "all of them".