Andre Weissflog

Clean-up sokol-gfx stats reporting by floooh · Pull Request #1393 · floooh/sokol Fixes #1388. Breaking changes: sg_query_frame_stats() =>sg_query_stats() sg_disable_frame_stats() => sg_disable_stats() sg_enable_frame_stats() => sg_enable_stats() sg_frame_stats_enabled...

A small breaking update for querying rendering stats in sokol-gfx (*technically* it's breaking, but hardly any code should actually be affected):

github.com/floooh/sokol...

...also nothing wrong with describing the entire build in a single CMakeLists.txt file in the root directory, at least that way the build complexity is immediately visible instead of hidden in the project directory structure...

But tbh: if a build script is so complex that it needs debugging, then that's already a big red warning sign ;)

> Sharpmake is written in C# and you can step into/debug your build code.

CMake has debugging support since somewhat recently:

devblogs.microsoft.com/cppblog/intr...

Ok, should be fixed now when you update your fork. I basically changed `std.fs.accessAbsolute()` to `std.fs.cwd().access()` and that seems to work:

github.com/floooh/sokol...

I also enabled the wasm build again (since the CI is pinned to 0.15.2)

With some dbg output:

Locally `dot_emsc_path` is

/Users/floh/.cache/zig/...

...but in CI it's:

.zig-cache/...

E.g. for some reason when running in CI there is no global zig cache...

ci: enable wasm build · floooh/sokol-zig@45704fc Zig bindings for the sokol headers (https://github.com/floooh/sokol) - ci: enable wasm build · floooh/sokol-zig@45704fc

PS: I can reproduce the problem in CI:

github.com/floooh/sokol...

...so it's not just you :)

Hmm that looks completely unfamiliar... looks like the `dot_emsc_path` here isn't absolute:

github.com/isurakka/sok...

That part is admittedly hacky, but not sure why it would break in CI but not locally.

wasm32-emscripten started to depend on clib thread functions · Issue #25856 · ziglang/zig Zig Version 0.16.0-dev.1236+26db54d69 Steps to Reproduce and Observed Behavior Since very recently, building the sokol-zig samples for wasm32-emscripten started to fail in the emcc link step becaus...

...the ticket for that problem is here btw:

github.com/ziglang/zig/...

There is a new port of zx2040 to the PicoCalc!
github.com/ohm69/zx-pic...

@flohofwoe.bsky.social

..correction :)

zig build -Dtarget=wasm32-emscripten run-cube

Yes 0.15.2 should work, e.g. in the sokol-zig dir:

zig build -Dwasm32-emscripten run-cube

The master breakage is about a pthreads dependency, so linking already shouldn't work.

...also funny: for C code I prefer 4 spaces intendation, for Typescript 2 spaces, not sure why. Somehow my TS code often ends up with deeper nesting than my C code.

...I guess the 'rational' explanation is that 1TBS works best for wide-screen displays because it doesn't waste vertical space (I code mostly on 14" laptops).

I went from:

if (...)
{
...
}
else
{
....
}

...to:

if (...) {
...
}
else {
...
}

...and then to:

if (...) {
...
} else {
...
}

...and that's what I'm sticking with now. Funny enough that's called the "One True Brace Style" ;)

...so in sokol_app.h there's now a fallback to create the D3D11 device without debug layer when the first attempt fails lol:

github.com/floooh/sokol...

...I also got my gaming PC into a state where the D3D11 debug/validation layer would no longer work (device creation simply failed), and the reason is that the D3D11 debug layer is an optional Windows component that's only installed on demand, and this install process was broken beyond repair...

Only slightly related, but I was wondering why my D3D11/DXGI backend had so much latency until I found out that one needs to explicitly call SetMaximumFrameLatency:

learn.microsoft.com/en-us/window...

...without that the rendering would always be 3 frames behind :/

A pretty wild debugging story:

When updating Dawn (Chrome's WebGPU lib), I saw a +50% jump in GPU timings for most/all of my GPU timers (measuring draws, dispatches, etc.).

I bisected Dawn's commit history to find the commit where the perf regression happened, and it ...

1/

Ok, the experimental sokol-gfx Vulkan backend has been merged:

PR: github.com/floooh/sokol...
Changelog: github.com/floooh/sokol...
Blog post: floooh.github.io/2025/12/01/s...

Remember that this currently only works on Linux, and has only been tested on an Intel GPU.

- Utilities to enforce monotonicity, e.g., for bounded quantities like colour. - More complete frame support: Frenet, Frenet with axis continuity, X + up - Jerk! Torsion! - Tessellation helpers for drawing plus some example code - Rotational splines, in particular, quaternion splines with C2 continuity and first and second derivatives provided, using the cumulative form from K/K/S.

I've pushed a few changes to my splines library, github.com/andrewwillmo..., recently, including:

Fixed! Thanks.

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)

...PS: the `!` in `!void` in the above screenshot is unnecessary (Zig doesn't catch that as an error yet), I was kinda expecting that std.c.fopen() returns a Zig error but instead it returns an optional pointer (and catching the null result is what the orelse is for).

...FWIW though, you can always directly poke through to `std.c` if you want to use the C file IO functions in Zig:

ziglang.org/documentatio...

...e.g.:

I also disagree with a lot of Zig stdlib design decisions though.
It's sort of like Vulkan at the moment. The entire focus is currently on performance and 'design purity', but not on usability/convenience.

Now is not a good time to do file IO in Zig because the entire IO system had just been rewritten completely and there's a ton of highlevel convenience functionality missing that was in the old std.fs API ;)

The new IO system is more like the complete low-level OS wrapper for POSIX-level services.

New project: ImAnim "Animation Engine for Dear ImGui" by @soufianekhiat.bsky.social
- Repo github.com/soufianekhia...
- Post github.com/ocornut/imgu...

Ooof, I think the wip blog post about the (experimental) sokol-gfx Vulkan backend will have about the same line count as the backend itself ;)

Pretty much an illustration of the current AI hype cycle ;)

E.g. using an ancient, sloppy and imprecise tool (the human language) to describe problems that require precision and determinism (computer programming).