zakarya/puzzles
1
0
Fork 0
mirror of git://git.tartarus.org/simon/puzzles.git synced 2025-04-20 23:51:29 -07:00
Code Issues Packages Projects Releases Wiki Activity

Update web puzzles to current WASM-based Emscripten.

Browse Source 
I presume this will improve performance. Also, if I've understood
correctly, WASM-based compiled web code is capable of automatically
growing its memory, which the previous asm.js build of the puzzles
could not do, and occasionally caused people to complain that if they
tried to play a _really big_ game in their browser, the JS would
eventually freeze because the emulated memory ran out.

I've been putting off doing this for ages because my previous
Emscripten build setup was so finicky that I didn't like to meddle
with it. But now that the new cmake system in this source tree makes
things generally easier, and particularly since I've just found out
that the up-to-date Emscripten is available as a Docker image (namely
"emscripten/emsdk"), this seemed like a good moment to give it a try.

The source and build changes required for this update weren't too
onerous. I was half expecting a huge API upheaval, and indeed there
was _some_ change, but very little:

 - in the JS initPuzzle function, move the call to Module.callMain()
   into Module.onRuntimeInitialized instead of doing it at the top
   level, because New Emscripten's .js output likes to load the
   accompanying .wasm file asynchronously, so you can't call the WASM
   main() until it actually exists.

 - in the JS-side library code, replace all uses of Emscripten's
   Pointer_stringify() function with the new name UTF8ToString(). (The
   new version also has an ASCIIToString(), so I guess the reason for
   the name change is that now you get to choose which character set
   you meant. I need to use UTF-8, so that the × and ÷ signs in Keen
   will work.)

 - set EXTRA_EXPORTED_RUNTIME_METHODS=[cwrap,callMain] on the emcc
   link command line, otherwise they aren't available for my JS setup
   code to call.

 - (removed -s ASM_JS=1 from the link options, though I'm not actually
   sure it made any difference one way or the other in the new WASM
   world)

 - be prepared for a set of .wasm files to show up as build products
   alongside the .js ones.

 - stop building with -DCMAKE_BUILD_TYPE=Release! I'm not sure why
   that was needed, but if I leave that flag on my cmake command line,
   the output .js file fails to embed my emccpre.js, so the initial
   call to initPuzzle() fails from the HTML wrapper page, meaning
   nothing at all happens.
This commit is contained in:
Simon Tatham
2021-04-03 08:42:04 +01:00
parent e1b9047b55
commit f6434e8496
4 changed files with 56 additions and 41 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
emccpre.js
View File

@ -486,15 +486,17 @@ function initPuzzle() {
}
});
// Run the C setup function, passing argv[1] as the fragment
// identifier (so that permalinks of the form puzzle.html#game-id
// can launch the specified id).
Module.callMain([location.hash]);
Module.onRuntimeInitialized = function() {
// Run the C setup function, passing argv[1] as the fragment
// identifier (so that permalinks of the form puzzle.html#game-id
// can launch the specified id).
Module.callMain([location.hash]);
// And if we get here with everything having gone smoothly, i.e.
// we haven't crashed for one reason or another during setup, then
// it's probably safe to hide the 'sorry, no puzzle here' div and
// show the div containing the actual puzzle.
document.getElementById("apology").style.display = "none";
document.getElementById("puzzle").style.display = "inline";
// And if we get here with everything having gone smoothly, i.e.
// we haven't crashed for one reason or another during setup, then
// it's probably safe to hide the 'sorry, no puzzle here' div and
// show the div containing the actual puzzle.
document.getElementById("apology").style.display = "none";
document.getElementById("puzzle").style.display = "inline";
};
}