You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looking at at the wavelib:gh-pages branch, I see that it loads a script called wavelib.js, which was apparently produced by Emscripten, but it's not really a wasm, but rather that "js asm" dialect. I've tried to fix it by producing a proper wasm binary from the src/*.c sources, but only found out that the demo uses a mysterious function cwave_transform that's not defined in any of those C sources. I've tried searching the entire github for it with no success. I guess that wavelib.js is a really old build of some C lib that's changed since then.
If you replace that wavelib.js with real wasm, the demo will be a lot faster (like 10x faster). Here's a bash script to produce wasm files:
The rest of the logic remain the same: index.html still loads wavelib.js, which behind the scenes, loads wavelib.wasm, and all calls to Module._cwave_transform and the like will be transparently routed to the wasm binary.
The text was updated successfully, but these errors were encountered:
On Sun, Aug 16, 2020, 03:21 wave-glsl ***@***.***> wrote:
Looking at at the wavelib:gh-pages branch, I see that it loads a script
called wavelib.js, which was apparently produced by Emscripten, but it's
not really a wasm, but rather that "js asm" dialect. I've tried to fix it
by producing a proper wasm binary from the src/*.c sources, but only
found out that the demo uses a mysterious function cwave_transform that's
not defined in any of those C sources. I've tried searching the entire
github for it with no success. I guess that wavelib.js is a really old
build of some C lib that's changed since then.
If you replace that wavelib.js with real wasm, the demo will be a lot
faster (like 10x faster). Here's a bash script to produce wasm files:
OUTPUT_FILE="./js/wavelib.js";
INPUT_FILES="./src/*.c";
echo "Building wasm from $INPUT_FILES to $OUTPUT_FILE";
emcc $INPUT_FILES -O3 \
-s WASM=1 \
-s EXTRA_EXPORTED_RUNTIME_METHODS='["cwrap"]' \
-s EXPORTED_FUNCTIONS="['_malloc','_free', 'cwave_transform']" \
-s ALLOW_MEMORY_GROWTH=1 \
-s FILESYSTEM=0 \
-o "$OUTPUT_FILE";
The rest of the logic remain the same: index.html still loads wavelib.js,
which behind the scenes, loads wavelib.wasm, and all calls to
Module._cwave_transform and the like will be transparently routed to the
wasm binary.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#26>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAI3RO7V6OOQLCC757DLEWDSA37MNANCNFSM4QAPGARQ>
.
Looking at at the
wavelib:gh-pages
branch, I see that it loads a script calledwavelib.js
, which was apparently produced by Emscripten, but it's not really a wasm, but rather that "js asm" dialect. I've tried to fix it by producing a proper wasm binary from thesrc/*.c
sources, but only found out that the demo uses a mysterious functioncwave_transform
that's not defined in any of those C sources. I've tried searching the entire github for it with no success. I guess thatwavelib.js
is a really old build of some C lib that's changed since then.If you replace that
wavelib.js
with real wasm, the demo will be a lot faster (like 10x faster). Here's a bash script to produce wasm files:The rest of the logic remain the same: index.html still loads wavelib.js, which behind the scenes, loads wavelib.wasm, and all calls to
Module._cwave_transform
and the like will be transparently routed to the wasm binary.The text was updated successfully, but these errors were encountered: