sokol-samples

Slug doesn't use "bitmap" font data but more like parameter lookup tables in storage buffers, pre-processed from TTF files. The lookup data can of course also live in textures (so that it works in WebGL), but using those textures as "poor-man's storage buffers", e.g. fetching the data directly without filtering. The pixel shader is indeed quite complex compared to SDF: https://github.com/floooh/sokol-samples/blob/8afa83928ce1870...

Here's a simple Slug rendering example on top of sokol_gfx.h: via WebGPU backend: https://floooh.github.io/sokol-webgpu/slug-sapp.html via WebGL2 backend: https://floooh.github.io/sokol-html5/slug-sapp.html There's quite a bit of helper code plus stb_truetype.h and stb_ds.h under the hood to parse TTF files and crunch the TTF curve data into the runtime format expected by the Slug shader (this stuff should better go into an offline asset pipeline tool): https://github.com/floooh/sokol-samples/blob/master/libs/slu... ...the actual text rendering code is also taking a couple of shortcuts, e.g. no kerning, no right-to-left, and also no text shaping. There's also a new and complete text rendering stack by Mikko Mononen called Skribidi (AFAIK not based on Slug though): https://github.com/memononen/Skribidi ...the list of external dependencies

I wrote a little demo to run microui on top of the sokol headers here, it's really interesting in how minimal it is. WASM demo: https://floooh.github.io/sokol-html5/sgl-microui-sapp.html Source code: https://github.com/floooh/sokol-samples/blob/master/sapp/sgl... The renderer backend is just a bunch of C functions you need to provide: https://github.com/floooh/sokol-samples/blob/3f4185a8578cd2b... It's also interesting to compare the binary sizes: microui sample (https://floooh.github.io/sokol-html5/sgl-microui-sapp.html): 79.6 KBytes compressed download Nuklear sample (https://floooh.github.io/sokol-html5/nuklear-sapp.html): 155 kb compressed download Dear ImGui sample (https://floooh.github.io/sokol-html5/imgui-sapp.html): 491 KB compressed download

> ImGui has C++ API as first-class citizen Dear ImGui via the C bindings is actually quite nice and not much less convenient than the C++ API (the only notable difference is that the C API has no overloads and default params). E.g. here's a control panel UI (from the below ozz-animation sample) with the 'Dear Bindings' approach (using a custom 'ig' prefix)): https://github.com/floooh/sokol-samples/blob/d8429d701eb7a8c... Dear ImGui is a bit of an outlier for C++ libraries though, since it is essentially a C API wrapped in a namespace. OzzAnimation is also fairly trivial to wrap in an (abstracted) C API, for instance I use this in some of the sokol-samples: https://github.com/floooh/sokol-samples/blob/master/libs/ozz... Implementation: https://github.com/floooh/sokol-samples/blob/master/libs/ozz... ...used in this sample: https://github.co

Any language feature added in C99 and later. In GCC and Clang it's quite relaxed since their C++ frontends pull in a couple of modern C features as non-standard C++ extensions, but MSVC has a strict separation between the C++ and C frontend and doesn't allow this sort of 'cross-pollution'. As a quick example, this C99 code block has at least 4 features that don't work in C++: https://github.com/floooh/sokol-samples/blob/91bd8c6f9f52149... - taking the address of an adhoc-created struct in a function call - random array access in struct initialization - designator chaining in struct initialization - designators can be out-of-order in C but not C++ ...also using unions as different views on the same memory is actually useful sometimes.

Explain why? Have you used C99 designated init vs other languages? E.g. neither Rust, Zig nor C++20 can do this: https://github.com/floooh/sokol-samples/blob/51f5a694f614253... Odin gets really close but can't chain initializers (which is ok though): https://github.com/floooh/sokol-odin/blob/d0c98fff9631946c11...

I don't know sorry. For debugging GL I usually switch to Windows with RenderDoc (or some current NVIDIA tool - does Nsight still exist?). RenderDoc on Linux appears to work fine for X11 apps via XWayland btw (just testing here via the sokol-samples with the sokol-gfx GL backend: https://github.com/floooh/sokol-samples, just another reason to not have a native Wayland backend but instead rely on the XWayland shim I guess...