Closed zigster64 closed 1 year ago
zigster64
commented
1 year ago Note that the demos on your hosted site work perfectly in the browser here - audio quality is perfect too, so its no a weird Mac M1 issue
Would be some weirdness in the 0.11 build process I think
zigster64
commented
1 year ago Found the problem - and applied some partial fixes
Seems that latest zig needs export_symbol_names array set on each step to tell it exactly which functions in the WASM file are to be exported for the JS to see
I guess its nice to be so explicit ... but more work
I have fixed a few, trying to get the others to work now.
zigster64
commented
1 year ago So with that change in place - Just Mandelbrot and Synth fail.
Everything else is good - including bat game, doom, tinyGL, etc
When Mandelbrot and Synth fail - they show nothing in console, and the browser tab becomes unresponsive. There are no errors about unexpected symbols. Still having a look with that
ringtailsoftware
commented
1 year ago Thanks for investigating this. I have been building with zig 0.11.0-dev.1507+6f13a725a on linux/aarch64.
I'll try updating too
ringtailsoftware
commented
1 year ago I've just tried with the latest, 0.11.0-dev.1912+12b74b2c0. I needed to update build.zig's target and optimize settings as you did, but I don't seem to need to export symbols explicitly.
Everything worked except mandelbrot. I've reduced the number of iterations it does and now it's ok. It may have just been very slow...
Can you try my "0.11.0-dev.1912+12b74b2c0" branch https://github.com/ringtailsoftware/zig-wasm-audio-framebuffer/tree/0.11.0-dev.1912%2B12b74b2c0
ringtailsoftware
commented
1 year ago "make" will now create an environment with the latest zig master, build and run the results in a local webserver. Github is automatically running just the build.
zigster64
commented
1 year ago interesting
OK, with Mandelbrot, tried it with ReleaseFast, and it does actually come up (with iterations 2000+) ... just a bit slowish
Dropped iterations down to 256, and its stupid fast. This is good.
Found this issue with some discussion in the last 4 days : https://github.com/ziglang/zig/issues/14818
but ... I added
lib.rdynamic = true back into my build.zig code, and commented out the bit where it sets explicit exports, and yep, that seems to do the trick with fixing the need to denote the exports. Leaving lib.rdynamic as the default, it throws an error about missing exports. I guess that's what's causing the exports issue then.
Man this is good ! What a blast
Only just hacked together an update of this to 0.11-dev latest, so its NOT a bug report so much as a set of initial findings
Got a weekend coming up to have a play with this and attempt to resolve
tiny changes here to force it to compile with the latest and greatest improvements to std.build: https://github.com/zigster64/zig-wasm-audio-framebuffer/commit/21da8a763b4357d0d4483b1fbc6b8a8597948576
Im seeing a decent set of WASM artefacts in zig-out, so looks like its building something sensible
When I run them in the browser, there is a variety of errors though, will sort through them one at a time and try to fix
sinetone
Chrome on M1 / Ventura :
wasmpcm.js:44 Uncaught TypeError: globalInstance.exports.getLeftBufPtr is not a function at pcmProcess (wasmpcm.js:44:47) at update (wasmpcm.js:174:13)
Safari on M1 / Ventura :
TypeError: globalInstance.exports.getLeftBufPtr is not a function. (In 'globalInstance.exports.getLeftBufPtr()', 'globalInstance.exports.getLeftBufPtr' is undefined)
Safari / Chrome on i7 Mac / Monterey
Other sound demos - same same
Mandelbrot
Thought this might have a different problem, because it shouldn't have audio (??? haven't really checked though ???) Same issues as above
Anyway, stuff for the weekend to play with and I will see where my setup is going wrong.
Awesome collection of code - thanks so much for posting this !