That was meant as a 1-pixel solution. Possible?

Simon maybe instead of using the distance formula (2 exponents addition and square root) you could do this method (sorry for the Pseudo code I don't know the powder toy well enough yet to write the exact code anyways):

int x1=312, Y1=234 // original electrode point being tested
int distance, shortestDistance

while (x<612)
while (y<384)
{
if(point=ELTR)
{
distance=abs[(x1-ELTR_X)+(y1-ELTR_Y)]
if (distance<shortestDistance)
shortestDistance=distance
}
}
}

It is much faster than exponents and square roots, Unfortunately there is a small bias rate, but it may be worth the speedup for checking large numbers of points. EDIT: If you rotated this image 45 degrees the square is the method above and the current method is the circle http://upload.wikimedia.org/wikipedia/commons/a/a7/Squaring_the_circle.svg. Basically you get great close up accuracy and less precise far away accuracy but it's much faster.

You may also want to run a quick check if any electrode is 1 pixel away before doing the main loop, greatly speeding up large plops of electrode.

Simon, my idea. Is it possible?

It should increase the performance much.

Maybe we should all relax on asking Simon and just wait ;)



The tl;dr is in 2 parts:

1.First test if any particles ETRD are immediately adjacent, this would greatly speed up any large plops of ETRD

2. Instead of using the distance formula to find the nearest circular distance use an approximation by finding the nearest diamond distance. It's much faster for a computer to find how far something is from the center of a square in a square grid than a circle, especially if it's doing it hundreds of times a second. there is a small tradeoff in accuracy though.


EDIT: For future reference #1 is most important #2 isn't really that important but a speedup nonetheless.

Simon:
So? It would increase performance by a great deal. Almost to the extent that they do not slow down the game more than the particles and the plasma would do alone.

@Simon: you can also run the for loop in nearest_part with multiple threads. doing a quick check with openmp (I don't know pthreads myself) it is a stable change.