When I .load() a new ANS or BIN file into a frame, does Frame.js just replace >all data and redraw every character in the entire frame? Or does it check the >new data against the old data to see if there are characters it can skip >repainting?
- If the frame needs a new tile, .load() it, then .draw()
When I .load() a new ANS or BIN file into a frame, does Frame.js just replace all data and redraw every character in the entire frame? Or does
it check the new data against the old data to see if there are characters it can skip repainting?
Before my optimizations, the average screen refresh was about 0.67 seconds. After the optimizations, they are down to 0.23 seconds. So it has made a pretty big difference.
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.
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 *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?
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.
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.
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 dimensions 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.
Sysop: | Clippy |
---|---|
Location: | Houston, TX |
Users: | 4 |
Nodes: | 4 (0 / 4) |
Uptime: | 74:14:54 |
Calls: | 1 |
Files: | 11 |
Messages: | 38,324 |