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
---
� Synchronet � Vertrauen � Home of Synchronet � telnet://vert.synchro.net
