Closed dfremont closed 9 years ago
I got a stack trace for this error (alas, I know nothing of JavaScript and didn't realize it was easy to do in Chrome), and it looks like the problem happens in the following expression in the base64 encoder in GiLoad:
String.fromCharCode.apply(this, arr)
Apparently there's some limit on the maximum number of arguments to a function, and that gets exceeded when the array arr
is too big. So if you try to load too big an image from the blorb, get_image_url
calls the base64 encoder on it and crashes. The PNG-vs-JPEG difference seems to have occurred just because the JPEG form of my image was below the critical threshold, and the PNG form wasn't. At any rate this serves me right I guess for not yet switching to this method instead of packaging the images in the base64-encoded blorb. Unless you want to support the latter, you can close this issue.
This should be fixed now with https://github.com/erkyrath/quixe/pull/8 .
(Fixed in the noeval branch. Will push to master in a few days.)
Quixe gives an error when I try to display image resource 1 if it is a PNG. If it's a JPEG or a different resource ID, it works fine. The error is: "Quixe init: RangeError: Maximum call stack size exceeded Maximum call stack size exceeded RangeError". This seems like a bug in Quixe, but I have no idea why these particular circumstances should be significant.
A simple way to reproduce this behavior is as follows. Release the following Inform story with PNG cover art of your choice (I haven't tried a variety of files, but it works with the default Inform cover art converted to PNG):
Use game2js.py to re-encode the blorb, since Inform fails to include figures when it does the encoding. Then run Quixe.