Weird codea slowing bug

Bugs
1

I found a weird codea bug while working on my fire. It runs comfortably at a stable 60 fps, but after a couple of minutes (sometimes much longer) fps pop down to 25. However when manipulating the sidebar, fps pop back to the stable 60 fps, until after a while it pops back to 25 etc.

If I do anything at all with the sidebar, scrolling through the parameters or the output, dragging the output bar or removing the sidebar altogether, the fps instantly pop back to 60.

At first I suspected a memory bug, but I’m not removing, creating or print()-ing anything and besides I’m not sure why updating the output window would fix that.

The ipad isnt going in sleep mode either because touching the screen elsewhere doesn’t do anything.

2

Maybe the sidebar causes a garbage collect. Try adding collectgarbage() in draw and see if it drops down.

3

Nope. I tried putting it in a number of different places in the code but same behaviour.

4

@Kirl After I posted that, I didn’t think it would work because it really doesn’t sound like a memory issue causing the slow down. Thought I’d have you try it anyways. Normally the only thing that causes a slow down is too much code being executed in draw. Do you have any for loops that are doing a lot of calculations. Does this code use shaders. I can’t remember for sure, but I think I had a shader that was really doing some heavy calcs and it’s like the shader was lagging behind and like building up until it slowed draw down to catch up. I can’t be sure about that and I don’t remember what I was doing with that shader. I don’t think I still have it anywhere.

5

There shouldn’t be too much calculations in the shader, however I did notice that using a wrong type of var can cause more problems than I would expect. Fragment shader code below.

//
// A basic fragment shader
//

//Default precision qualifier
precision highp float;

//This represents the current texture on the mesh
uniform lowp sampler2D texture;

uniform lowp float nrCols;
uniform mediump vec3 clr[3];

//The interpolated vertex color for this fragment
varying lowp vec4 vColor;

//The interpolated texture coordinate for this fragment
varying highp vec2 vTexCoord;

vec4 colorize()
{
    lowp vec4 pix = texture2D( texture, vTexCoord ) * vColor;
    float dStep = 1.51/3.;
    float gray = pix.r;
     
    float cr = mod(gray, dStep) / dStep;    // color mix ratio
    int ci = int( nrCols-gray / dStep -1. );   // color index
    
    vec4 c1 = vec4(clr[ci][0]/255., clr[ci][1]/255., clr[ci][2]/255., 1.);
    vec4 c2 = vec4(clr[ci+1][0]/255., clr[ci+1][1]/255., clr[ci+1][2]/255., 1.);
       
    return mix(c1, c2, 1.-cr)*gray;
}


void main()
{
    //Sample the texture at the interpolated coordinate
    lowp vec4 col = texture2D( texture, vTexCoord ) * vColor;
    
    //Set the output color to the texture color
    gl_FragColor = colorize();
}

Passing nrCols shouldn’t be necessary, because afai could find we can’t dynamically set or get table.length() in glsl es2. Though I would love to be corrected on this because right now this shader only works with exactly 3 colors.

I also kinda botched the dStep calculation until it worked (could’ve hard coded it as it stands), maybe there’s an accumulating error in there?

Using a colormap aproach like @LoopSpace suggested in the other thread would fix these problems and remove pretty much all calculation as well, but getting this to work first provided some good shader practise. =)

6

@Kirl I was never able to pass a variable to a shader to change the length of a table. It always had to be hard coded. Have you tried hard coding the colors in the shader to see what that does. Can you comment out some of the shader code line by line to see if something there is a problem. Maybe don’t call the shader at all to start.

7

Doh, I should’ve thought of that in the first place, it’s not the shader… Same behaviour.

I found the hacky-est fix ever though! I wanted to print out some values when the fps got below 30, but because that updates the output window it fixes itself after only one frame! =)

I did finally locate the bug though and it has something to do with the size at which I draw the particles, but I’m still entirely confused as to why this would cause this weird behaviour.

Fps sharply drop, but only after a little while, even though I increase all particle sizes simultaneously. The duration after which the fps drop seems to shorten the bigger I make the particles. So it seems like some sort of accumulating error somewhere.

I’ll experiment some more.