Andre Weissflog

The one big advantage was that those 'poor-man's-compute' tricks also worked on WebGL and on ancient hardware :)

Emscripten users: are you generally/often up to date, or is your app/product occasionally stuck on older versions, for whichever reason?

CI is using the latest stable emsdk, so I tend to stumble over build issues quickly. Locally I update maybe once a month, which with the current release cadence of about 2 weeks means that I sometimes skip an update for local dev work.

Not being able to update for a while is very rare.

dear imgui 1.92.4 released!
github.com/ocornut/imgu...

Bonus links:
- list of extensions github.com/ocornut/imgu...
- debug tools github.com/ocornut/imgu...
- error recovery github.com/ocornut/imgu...
- getting started github.com/ocornut/imgu...
- bindings & backends github.com/ocornut/imgu...

Hmm good point, I never thought about that too much. I guess for things like alloc/free of fopen/fclose I would still use defer even for 'single-exit-path' situations, but for something like the init/uninit calls of a library I would probably put the uninit at the end of the function instead 🤔

...e.g. I'm planning to do the same thing as with the sokol_gfx.h GL backend: only for Windows a minimal GL loader is integrated into sokol_gfx.h, but on all other platforms the GL DLLs are 'linked' like regular system DLLs without a loader.

Hmm, incidentally I also just started tinkering with Vulkan on Linux and I'm linking with the system vulkan dll like the other system libs (X11, ...), e.g. just -lvulkan, but without any "Vulkan loader" (just as GL doesn't need a GL loader on Linux).

I guess I'll need a 'loader' on Windows though..

"Oh no there's a Chocomel in my Playdate!" is back, but this time Chocomel is also on the web: aras-p.github.io/playdators/ and on github: github.com/aras-p/playd... #dogwalk #playdate

Yeah me too sometimes.

There's now a pretty good solution to debug directly on the WASM target via a VSCode plugin, but the debugger setup is still a bit more hassle than native debugging - question is what's more hassle, setting up WASM debugging, or setting up a Dawn build ;)

...for instance with static linking I was running into problems like having to link a C++ stdlib into an an otherwise pure C project (since Dawn is implemented in C++, not C), which isn't handled automatically by tools like cmake.

...for the future it might be the best idea to just pull a precompiled Dawn DLL + webgpu.h header during the build process instead of trying to inegrate the Dawn build process into the Dear ImGui build process.

DLL + header seems to be the least painful cross-platform solution.

...as I wrote elsewhere in the thread, if I were you I would only support the Emscripten+WebGPU combo at least for now. That's significantly less hassle than trying to integrate with a native WebGPU library, especially without prebuilt libraries.

...also arguably: what is even the point of supporting a native-WebGPU-library backend for Dear ImGui, when there are already backends for all relevant lower-level 3D APIs anyway?

On native platforms WebGPU just adds significant overhead over using the native 3D APIs directly.

I only use Dawn for local debugging of my WebGPU backend, but don't 'officially support' WebGPU in native scenarios (even though I added all the code to let people build sokol apps against native WebGPU libraries), I just don't want to currently waste time with support because it's a hassle.

I also have "opinions" about the new WebGPU C-API, but this would derail the thread ;)

FWIW - if at all - I would only support WebGPU for web targets, e.g. treat it more like Emscripten+WebGL2 special case instead of a multi-platform backend.

The situation on native is currently too complex (especially around compiling native WebGPU implementation libraries).

That's totally what Falcon on the Amiga looked like in my mind when I played it ;)

I guess it's clear for the millions of people switching from Java to Rust ;)

IMHO Ptr<T> or HeapPtr<T> would be a better name.

still messin' with this thing. so many yaks to shave when you start from scratch. autocomplete, filter dsp, sample loading, even json parsing. an eternal pile of todos, but each one small enough I'm making slow but continual forward progress...

Btw, re json parsing:

github.com/rxi/sj.h

...haven't used it myself though yet :)

That could need a whole presentation of its own just for Germany ;)

(e.g. the most radical change that happened since the 1980's or so is that WW2 games don't actually need to replace the Nazi swastika with some placeholder symbol anymore yet most international publishers still keep doing it)

...and not to mention the huge difference to running Win11 on that same laptop. It's like suddenly the laptop has lost at least half of its performance compared to KDE Plasma 6 ;)

...it's really weird that Apple is so much behind with their display technology now that I can get random PC laptop that's significantly cheaper than a similar MBP, and the PC laptop has a *much* better display than the Mac.

Tbf though, except for the missing sound, KDE Plasma 6 is absolutely wonderful on that laptop, it slick and fast and looks great. For my programming tasks it feels just as fast as my M1 MBP (with the downside though that the Asus gets really hot when compiling).

Typo: Intel Meteor *Lake* laptop (an Asus Zenbook 14 OLED)

...case in point: my Intel Meteor laptop had broken sound on Ubuntu 24, then it was fixed in some Ubuntu 24 update, and now it's broken again in Ubuntu 25 - and IMHO that describes the state of the Linux desktop perfectly ;)

At least the touchpad feels good now though.

I bet that most of that is Steam Deck though (e.g. doesn't suffer from the dreaded Linux Desktop fragmentation).

But it might actually be a very good thing if the vast majority of Steam Linux users is on Steam Deck. Maybe at some point Valve will bring back the idea of the Steam Box.

New sokol-gfx update: this adds a 'sg_draw_ex()' function which takes additional base_vertex and base_instance parameters. See changelog for details:

github.com/floooh/sokol...

...and a new sample (needs WebGPU): floooh.github.io/sokol-webgpu...

I don't know though... designing an API which hides a complex copy-operation under an innocent looking array-access still strikes me as really dumb ;)

It's like the next level of C++ operator overloading abuse.

What's wrong with simple SetPosition(index, ...), GetPosition(index) functions?

The more the merrier I say ;) E.g. better than up to the early 2010s when there were pretty much no modern alternatives for C and C++. That's the one great achievement of LLVM, it 'democratized' language development.