Subj : Another Frame.js question
To   : Kirkman
From : echicken
Date : Thu Oct 15 2015 12:47 am

  Re: Another Frame.js question
  By: Kirkman to echicken on Wed Oct 14 2015 11:10:18

 Ki> I don't *think* I'm asking too much of the system memory-wise, but maybe
 Ki> I'm wrong. If you have a minute could you take a look and tell me if you
 Ki> have any thoughts on the out-of-memory issue, or the wrong data
 Ki> dimensions? 

By default, Synchronet places some tight limits on how much memory can be used
by javascript modules. See JavaScriptMaxBytes and JavaScriptContextStack in
sbbs.ini. I believe that the idea here is to save people from their own
(inadvertently) memory-hungry code.  These values are fairly reasonable for
more typical BBS modules.

If you find that you actually need to allow JS modules to use more memory, you
can bump these values up.  On a test BBS, I got around the 'Out of memory'
error when running your script by bumping the ContextStack value up to 512K
from the default 16K.  (That's quite a jump, but then again on my main BBS I
have these values set higher, I don't recall by how much.)  Some rough math
suggests that if every character cell in your 128x112 graphic was occupied, and
repeated over 24 frames, you might need more than that.  The overhead of the
Frame objects would need to be allowed for as well.

 Ki> Additionally, when I try to debug the errors, Frame.js is giving the wrong
 Ki> data dimensions for my tileset files. As I said, the tileset is 128x112,
 Ki> but if I call .data_width and .data_height after .load()ing, I get 17x832
 Ki> for the .ANS version or 129x112 for the BIN. 

I generally use .BIN files for loading into frames.  The data_width of 129 in
this case suggests that something is slightly off (by one) in the way that
Frame is reporting this.  At a glance, it looks like Frame is adding 1 to this
value ... for reasons I do not know.  I'll ask mcmlxxix if he remembers why
it's doing this.  For now, just subtract 1 from your data_width, and that's the
real number.

The data_width of 17 for the .ANS file would be a two-part issue.  Again,
data_width would actually be 16 in this case, which is the width of the frame
in question.  Apparently when loading a .ANS file, Frame wraps the loaded
content to the width of the frame.  I can't imagine why, but maybe there's a
reason - so I won't change it just yet and will just suggest that you use .BIN
instead.

---
echicken
electronic chicken bbs - bbs.electronicchicken.com - 416-273-7230
 þ Synchronet þ electronic chicken bbs - bbs.electronicchicken.com

.