Table memory limit?

I'm getting some strange results with large tables. Do you have some limit to how large tables can be or memory usage in general for a script?

Yep - it may very well be errors in the script though

script:

Quote

function setPixRGBA(buf,cx,cy,r,g,b,a) cx = math.floor(cx) cy = math.floor(cy) --zero indexed! if (cx >= 0) and (cx < OUTPUT_WIDTH) and (cy >= 0) and (cy < OUTPUT_HEIGHT)then i = (cx + cy * OUTPUT_WIDTH) * 4 + 1 buf[i] = r buf[i + 1] = g buf[i + 2] = b buf[i + 3] = a end end; function getPixRGBA(buf,cx,cy) cx = math.floor(cx) cy = math.floor(cy) --zero indexed! if (cx >= 0) and (cx < OUTPUT_WIDTH) and (cy >= 0) and (cy < OUTPUT_HEIGHT)then local i = (cx + cy * OUTPUT_WIDTH) * 4 + 1 local r = buf[i] local g = buf[i + 1] local b = buf[i + 2] local a = buf[i + 3] return r,g,b,a end return {0,0,0,0} end; function createBitmap(buf, src) local sx = 1 / OUTPUT_WIDTH local sy = 1 / OUTPUT_HEIGHT for j=0,OUTPUT_HEIGHT-1 do for i=0,OUTPUT_WIDTH-1 do local r,g,b,a = get_sample_map(i*sx, j*sy, src) setPixRGBA(buf, i, j, r,g,b,a) end end end function prepare() bitmap = {} initialize = true end; function get_sample(x, y) if (initialize == true) then createBitmap(bitmap, SOURCE) initialize = false end -- do not work: --local r,g,b,a = getPixRGBA(bitmap, x * OUTPUT_WIDTH, y * OUTPUT_HEIGHT) -- works, but with error: local r,g,b,a = getPixRGBA(bitmap, 300, 300) return r,g,b,a end;

Bitmap Buffer.ffxml

Heh, I've fixed this =)
Script code after bug fixing:

Quote

function setPixRGBA(buf, cx, cy, r, g, b, a) local cx = math.floor(cx) local cy = math.floor(cy) --zero indexed! if (cx >= 0) and (cx < OUTPUT_WIDTH) and (cy >= 0) and (cy < OUTPUT_HEIGHT)then local i = (cx + cy * OUTPUT_WIDTH) * 4 + 1 buf[i] = r buf[i + 1] = g buf[i + 2] = b buf[i + 3] = a end end; function getPixRGBA(buf,cx,cy) local cx = math.floor(cx) local cy = math.floor(cy) --zero indexed! if (cx >= 0) and (cx < OUTPUT_WIDTH) and (cy >= 0) and (cy < OUTPUT_HEIGHT)then local i = (cx + cy * OUTPUT_WIDTH) * 4 + 1 local r = buf[i] local g = buf[i + 1] local b = buf[i + 2] local a = buf[i + 3] return r, g, b, a end -- Fixed(Egret): return {0, 0, 0, 0} is incorrect here return 0, 0, 0, 0 end; function createBitmap(buf, src) -- Fixed(Egret): it's a proper conversion from the filter coords to -- the image coords local scale = 1 / SIZE for j=0, OUTPUT_HEIGHT-1 do for i=0, OUTPUT_WIDTH-1 do local r,g,b,a = get_sample_map(i*scale, j*scale, src) setPixRGBA(buf, i, j, r, g, b, a) end end end function prepare() bitmap = {} initialize = true end; function get_sample(x, y) if (initialize == true) then createBitmap(bitmap, SOURCE) initialize = false end -- Fixed(Egret): it's a proper conversion from the filter coords to -- the image coords local r,g,b,a = getPixRGBA(bitmap, x * SIZE, y * SIZE) return r,g,b,a end;

Another point of discussion is coordinate systems used in FF.
We are going to post an wiki article about it this week.

Ah, of course! Remains of my first implementation where I tried to store channels in a small table for each rgba pixel/sample, but that didn't work out (maan I wish I could drag off the script tab and maximize it hint hint)

About the memory consumption - yes I did notice things got slow with the "large" table. I am really just testing/learning things by trying out familiar concepts from earlier projects.

Are you saying that the complete script is copied for each thread or what is going on? It would be quite useful if you somehow could declare a shared variable cross threads and script components, perhaps in some sort of read only state to avoid changing data problems. Or the other way around: declare that a script is not suitable for multithreaded processing.

I think that you will see several attempts to implement bitmap filters, perhaps something can be done in this regard (some sort of bitmap filter script component which is wrapped by your general bitmap filter framework, with cache tiles etc).

Quote
Sphinx. wrote: (some sort of bitmap filter script component which is wrapped by your general bitmap filter framework, with cache tiles etc

This is planned, but it won't make it into the official release of 2.0.

Perhaps with the official release of version 5.0, then?

Does version 6 help this by eliminating the 32 bit 3 GB limit?