diff options
| author | Ben Harris <bjh21@bjh21.me.uk> | 2023-04-03 15:16:35 +0100 |
|---|---|---|
| committer | Ben Harris <bjh21@bjh21.me.uk> | 2023-04-03 21:09:57 +0100 |
| commit | 36c282aaa92bd42d570cdc76fe3b9e76d8da1ff1 (patch) | |
| tree | 4661801830ff0e3a064585db74d63ee7a2299621 /nullgame.c | |
| parent | 8d3a93ce47237114a88d8bed81ab175994eb9a6b (diff) | |
| download | puzzles-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 'nullgame.c')
0 files changed, 0 insertions, 0 deletions