Sepehr Taghdisian

GitHub - septag/OffsetAllocator: Fast O(1) offset allocator with minimal fragmentation. Single C-Header library version. Fast O(1) offset allocator with minimal fragmentation. Single C-Header library version. - septag/OffsetAllocator

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.

There are many internal and architectural changes to Vulkan backend too. I'm going for the 1.3 core features plus descriptor buffers (VK_EXT_descriptor_buffer) support. It was a bit of challenge to get around it initially and the debugging process. But I feel it's well worth it. It's quite powerful.

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)

Great job! It might actually be the right time for devs to start making stuff with Vulkan. After almost a decade if it's release. :)

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.

YouTube video by Wookash Podcast If you're serious about programming, listen to Stewart Lynch

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.

But one major drawback of having such control and power is that it's so easy to over-engineer, over-abstract and come up with generalized abstraction API designs that could make your backend perform worse than D3d11 drivers. (5/5)

The API is obviously not perfect at all, although it took me about 4~5kloc to do basic imgui rendering, but the control freak in me is satisfied with how much control you have over memory, queues and multi-threaded rendering. (4/5)

The latter confused me a lot on how frame and swapchain syncing and syncing in general. The former starts with 1.3 and is better organised for beginners. (3/5)

My first try was about 2 yrs ago, but then recently I had to revisit all the stuff again and rewrite my toy rendering backend to learn it more properly. I think newcomers, better start with vkguide.dev tuts instead of vulkan-tutorial.com (2/5)

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)

saw your post on x. community got divided so I guess like u I had to get another account here to follow up on the ppl I like

seems like bsky doesn't support animated GIF, bummer!

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".