aboutsummaryrefslogtreecommitdiff
path: root/Makefile.doc
diff options
context:
space:
mode:
authorBen Harris <bjh21@bjh21.me.uk>2023-04-03 15:16:35 +0100
committerBen Harris <bjh21@bjh21.me.uk>2023-04-03 21:09:57 +0100
commit36c282aaa92bd42d570cdc76fe3b9e76d8da1ff1 (patch)
tree4661801830ff0e3a064585db74d63ee7a2299621 /Makefile.doc
parent8d3a93ce47237114a88d8bed81ab175994eb9a6b (diff)
downloadpuzzles-36c282aaa92bd42d570cdc76fe3b9e76d8da1ff1.zip
puzzles-36c282aaa92bd42d570cdc76fe3b9e76d8da1ff1.tar.gz
puzzles-36c282aaa92bd42d570cdc76fe3b9e76d8da1ff1.tar.bz2
puzzles-36c282aaa92bd42d570cdc76fe3b9e76d8da1ff1.tar.xz
js: Load save files into the C side incrementally
Before this commit, JavaScript Puzzles loaded a save file by pushing the entire file onto the Emscripten stack and then reading it from there. This worked tolerably for typical save files, but Emscripten's stack defaults to only having 64 kiB of space. That meant that trying to load something that wasn't a real save file tended to cause a stack overflow. I expect that at least some real save files would suffer from the same problem. The stack overflow would generally cause a JavaScript exception and then leave the stack pointer outside the stack, so that any future attempt to call into C would fail as well. To fix this, arrange that the C function for reading data from the save file calls out to JavaScript. The JavaScript can then copy just the requested data into the caller's buffer. We can't pass a JavaScript function pointer to C, but since only one file can be loaded at a time, we can just have a global variable that's the current loading callback. There might still be a problem if you try to load a stupendously large file, since I think FileReader.readAsArrayBuffer() reads the whole file into the browser's RAM. It works on my laptop with files up to a few hundred megabytes, though.
Diffstat (limited to 'Makefile.doc')
0 files changed, 0 insertions, 0 deletions