>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.
Thanks, I didn't realize these settings were configurable in SBBS. I think I wil
l try to stick to Synch's default settings for memory.
It occurs to me that I can combine my frame "re-painting" method with the tilesh
eet method: Make one invisible "holder" frame that loads the entire tileset at t
he beginning. Then on each redraw, copy data out of the holder to paint those ch
aracters that have changed in the visible frames. By loading only one copy of th
e tileset, I should have no memory issues, and I'll also get the benefit of no l
onger constantly loading individual tile BIN files.
>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.
>
>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 thought data_width and _height properties were supposed to be the true dimensi
ons of the loaded image, since you can use offset to scroll that image around in
the frame. But, yeah, until that's sorted, I'll stick to BINs.
--Josh
---
■ Synchronet
|
