Flaw in fusing of flame iteration

[roever]

This code in flam3.c looks strange to me... what does it do?

  if (apply_xform(cp, fn, p, q, rc)>0) {
     consec ++;
     badvals ++;
     if (consec<5) {
        p[0] = q[0];
        p[1] = q[1];
        p[2] = q[2];
        p[3] = q[3];
        i -= 4;
        continue;
     } else
        consec = 0;
  } else
     consec = 0;

if you instead use something like this

if (apply_xform(cp, fn, p, q, rc)>0) { consec = 0; badvals ++; p[0] = q[0]; p[1] = q[1]; p[2] = q[2]; p[3] = q[3]; i -= 4; continue; else if (consec < fuse) consec++; p[0] = q[0]; p[1] = q[1]; p[2] = q[2]; p[3] = q[3]; i -= 4; continue }

this restarts the fuse process whenever a badvalue happened and we got back a random value... if we don't we get shadows of the square around the origin in the fractal. Compare the two images in

https://imgur.com/a/4WAxU

this is mostly invisible in normal flames... but it shows up quite often in very simple ones. I've appended the flame that was used to create those images

test91_cosh.flam3.txt

[EReckase]

Neat. I think the alternate fuse process you suggest definitely improves the resulting image.

[PeterBBBBB]

I tried implementing the "something like this" exactly as

if (apply_xform(cp, fn, p, q, rc)>0) {
    consec =0;
    badvals ++;
    p[0] = q[0];
    p[1] = q[1];
    p[2] = q[2];
    p[3] = q[3];
    i -= 4;
    continue;
}
else if (consec < fuse) {
    consec++;
    p[0] = q[0];
    p[1] = q[1];
    p[2] = q[2];
    p[3] = q[3];
    i -= 4;
    continue;
}

but I am finding that flam3-genome now often locks up in a cpu loop. Specifically using seeds 13 & 18 for example. Is there maybe a typo in here? Agree the test image is much improved.