Finalize WASM and zig-0.12.0 support (see #50)

[floooh]

• [x] add WebGL2 and WebGPU shaders
• [x] fix WebGPU support
• [x] Emscripten linker step: automatically scan for library dependencies instead of taking a single hardwired lib_sokol
• [x] Emscripten linker step: use -Oz for ReleaseSmall and -O3 for ReleaseFast
• [x] Emscripten linker step: allow passing additional args as string slice
• [x] update readme
• [x] mention -sUSE_OFFSET_CONVERTER requirement for Emscripten linker option when using Zig allocators
• [x] fix pacman.zig
• [x] fix kc85.zig
• [x] add shell.html file
• [x] fix wasm-emscripten on Windows (detection of Windows was broken before emsdk script)
• [x] run emsc install+activate only once
• [x] final test on macOS
• [x] final test on Linux
• [x] final test on Windows

...not this time, but should be considered for an update

• figure out what it takes to wrap the Emscripten linker step into a "proper" CompileStep instead of a RunStep (see https://discord.com/channels/605571803288698900/1145919498801655839/1196554903192092672)
• consider using this trick: https://discord.com/channels/605571803288698900/1196130804665942247/1196142315090231426

[floooh]

@kassane fyi 👆(PR into master to keep track of what I'm adding... e.g. the black screen samples are working now...

[kassane]

@kassane fyi 👆(PR into master to keep track of what I'm adding... e.g. the black screen samples are working now...

Amazing!

[floooh]

Now with a shell.html which fills the whole client area :)

[floooh]

KC85 emulator running in browser (wasn't supported before, but quite trivial now):

[kassane]

On: https://github.com/floooh/sokol-zig/pull/51/commits/a2e4b461d6a78ab4f542e2aef391bde424175173

Does this do a recursive dependency lookup on libsokol? For example, if you had any examples that used cimgui, would it link it directly to sokol so that emcc would pull both of them?

[floooh]

The idea is that one could add additional C library compile steps (like for instance cimgui) to the top-level module (same as happens with the sokol C library), and the Emscripten linker step would pick those up automatically.

I don't actually know whether it's fully recursive, but for the cimgui case, I wouldn't add that dependency to the sokol module, but to the 'Zig main module' (obviously that loop which scans for dependencies isn't recursive, but I don't know if the 'dependency iterator' does that for me... from looking around in the stdlib where this dependency iterator is used, all places I saw don't have any sort of 'explicit recursion', but still seem to walk over all dependencies).

I haven't actually tested it though, only made sure that it discovers the sokol library dependency.

[floooh]

Whoop whoop!

[kkukshtel]

@floooh Been tracing through these changes as I look to move my own sokol-based engine to work with wasm. If the intention is that sokol is being comsumed as a wasm module directly (DLL-like), is it sufficient to use wasm32-freestanding or does sokol always require the intermediate emscripten step (and hence the build.zig template here) for the EM_JS() stuff you mentioned in another thread?

[floooh]

@kkukshtel yeah, you'll need to compile the sokol C library as wasm32-emscripten, and link the final executable (or WASM 'DLL' I guess) with the Emscripten linker.

Decoupling the sokol headers from Emscripten is currently not feasable unfortunately (since even without the use of EM_JS, it would require writing our own browser API shims and/or parts of the Emscripten helper functions).