Putting this here as I consider my question hypothetical, I don’t actually need the answer per se. So:
Assuming an integer coordinate system, is it possible to calculate all the points that are within a circle of center point P, and radius R?
Couldn’t come up with a solution that didn’t involve brute forcing it, ie getting all the possible points and doing something like
circle.contains(currentPoint);
Any thoughts?
Whats the problem to begin with?
the simplest way would be firstly to calculate all the points that the circle has along its shape then calculate every point within the diameter of the object that are within those bounds
so you would need a list of verticies[] then run through the circle where for (int i = 0 ; i < pi * 2 * r,i++){ verticies[i] = new vertex(r * cos(i),r * sin(i));} r should be the pixel increment , to figure out the points within that shape you take the square shape of the object.
Well, I’m considering having a try at a Worms clone, and after some research it seems collision detection etc is done via a bitmask that represents the terrain. Drawing a circle on a texture was easy, but I was wondering how to ‘draw’ a circle of falses in a boolean[][]. I figured I’d use the brute force approach, but was just wondering if there’s a more mathematical approach.
Hmm so it is possible, technically? Would this be quicker than the more brute force approach, would you say?
Why do you want to use a circle?
If you need pixel perfect collision detection the simplest approach is to use rectangles.
You have a big array that contains all the pixels of the terrain and another array that contains all the pixels of your worm. Then you can just go through the arrays and check if there are two pixels at the same spot.
To make this faster you can use bit masks. Which means that each entry in the array is an integer number and each bit in that number represents one pixel. You can then use xor to test for overlapping pixels.
You can just use the distance formula and check if the distance from the point to p is less than r.
Because explosions create circular holes 
also @Longarmx:
public boolean pointInCircle(Point point, Point circleCenter, float circleRadius)
{
return (
(point.x-circleCenter.x)*(point.x-circleCenter.x)+
(point.y-circleCenter.y)*(point.y-circleCenter.y)) <= circleRadius*circleRadius;
}
Believe this answers the original question.
Could brute force just 1 quadrant and mirror the results to the other 3.
Re. explosions: another way would be do it like a real explosion with a “wave of destruction” moving out from the point to all adjacent squares, reducing in power as it moves further out based on the density of the material (more damage to custard than steel!) Stop when all the wave’s power has been absorbed. Not sure of the details but seems like it would be fairly simple and not too CPU-intensive because it’s totally localized around the point.
Quadrant is overkill. You can get it to work fine with an octant.
No I meant like precompute a list of points, not check existing points to see of they fit. I’m not very good at articulating myself I’m afraid.
You could apply this to any possible point in a rectangular field.
Not very efficient, but hey.
That’s exactly what I’ll most likely end up doing I imagine for small circles it’ll be plenty fast enough. Premature optimisation and all that 
If you don’t want to reinvent the wheel, you can draw onto a buffer and use that instead of your boolean[][].
I’m not sure which algorithm the library will use to fill a circle, but to draw its outline the standard one is Bresenham’s algorithm. With that keyword you should be able to find far more explanations of it than you need.
Thanks for the tip some experimenting shows that grabbing the actual pixel alpha value from the pixmap is fast so I won’t bother with the [icode]boolean[][][/icode] at all.