Subj : Another Frame.js question
To   : Kirkman
From : Digital Man
Date : Wed Oct 14 2015 10:10 pm

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

 > >  Re: Another Frame.js question
 > >  By: Kirkman to All on Tue Jun 09 2015 15:29:46
 >
 > >How many different kinds of tiles are there?  If each is saved as an
 > individual
 > >.bin or .ans, you might try combining them all into a single spritesheet.
 > Load
 > >the entire spritesheet into each 16x16 frame, then scroll the frame to
 > >different x/y offsets as needed to reveal the desired portion of the larger
 > >graphic.  This would cut out the .load() and .draw() calls, as .cycle()
 > (which >I assume is being called regularly on the overall parent frame)
 > should take >care of redrawing all child frames as needed.
 >
 > I finally got around to trying your suggested tileset approach, and I ran
 > into a a couple roadblocks. Let me explain.
 >
 > I'm taking a 132 char x 60 char canvas and dividing it into an 8x3 grid of
 > frames. Each frame holds a 16 char x 16 char tile.
 >
 > In my test code, I'm iterating over each frame and .load()ing my tileset.
 > The tileset is 128x112. I have tried various versions of this tileset, as an
 > ANSI file, a BIN file, with SAUCE or without. No matter what, I always run
 > out of memory.
 >
 > Additionally, when I try to debug the errors, Frame.js is giving the wrong
 > data dimensions for my tileset files. As I said, the tileset is 128x112, but
 > if I call .data_width and .data_height after .load()ing, I get 17x832 for
 > the .ANS version or 129x112 for the BIN.
 >
 > I don't *think* I'm asking too much of the system memory-wise, but maybe I'm
 > wrong. If you have a minute could you take a look and tell me if you have
 > any thoughts on the out-of-memory issue, or the wrong data dimensions?

I don't really know anything about frame.js (except vaguely that it exists), so
I can't really help specifically with that, but regarding the memory usage: you
can allocate more memory to the JS runtime via your configuration
(JavaScriptMaxBytes in http://wiki.synchro.net/config:sbbs.ini#global). The
defualt is 8Mbytes, which logically, should be enough.

If a script is performing a lot of string manipulation, it might need to use
the new(is) js.flatten_string() method to reduce unnecessary memory
consumption.

Other methods of scope manipulation can encourage garbage  collection. You can
read/print the js.gc_attempts property to make sure garbage collection is
running and possibly manipulate js.gc_interval to make it happen more often.
It's certainly possible that there is a bug in the current code in regards to
JS memory usage/garbage collection.

                                            digital man

Synchronet "Real Fact" #24:
The Digital Dynamics company ceased day-to-day opperations in late 1995.
Norco, CA WX: 75.1øF, 72.0% humidity, 3 mph SE wind, 0.00 inches rain/24hrs

.