Lately I have been thinking about a way to draw a circle without the use of the sine and/or cosine and I thought of a way which I am not sure is the best way to do this.

Let?s say we are given the center point of the circle and its radius. We can now create a loop which iterates from Center.x-Radius to Center.x+Radius or maybe even downwards from Center.x+Radius to Center.x-Radius. Now we have one point on the radius which is the center of the circle and one point which we have the X to, which is located on the circumference. We can then calculate the Y position of this point using the distance formula as in:

Radius = Sqrt ((P1.x - P2.x) ^2 + (P1.y - P2.y) ^2)

We have the radius and the x, y position of the first point and also the x position of the second point, therefore, we are only left to find the y position of the second point. The final x and y position of the second point would be a point on the circumference, wouldn?t it be?

Wouldn't it be more concise to assume a radius of 1. Then define the x-range from -1 to +1 and step it in say 200 steps, so that you need to compute the corresponding y-value of x from -1,-.99,-.98,-97,...,0,.01,.02,.03,...,.97,.98,.99,1 . Then the y-values can be calculated simply by Pythagoras's theorem, which is plus or minus SQRT(1-X^2) for each x-value. If the radius is greater than 1, the x and y values can easily be scaled up. Ratch

Look up Bresenham's Circle Algorithm. It's very simple and doesn't need anything more than bit shifting and addition/subtraction, so it's highly regarded as the fastest circle drawing algorithm. The more general version of the algorithm also applies to arbitrary curves, and the line-specific version is very fast.

I believe that the Pythagorean Theorem states that in the right triangle, the length of the hypotenuse squared is equal to the sum of the squares of the other two sides. Therefore, if I have the x position which is put in iteration for example from -1 to +1 in a unit circle and I also have centre point I don?t think that I would be merely able to calculate the y position using that formula.

In that case, I will first have to find the line formula for the side of the right triangle with one point at the center and one at the x position in the iteration which is pretty easy with a fixed slope for infinite points on the vertical line. After that I have to find where the hypotenuse and the other side of the triangle intersect which would be a point on the circumference. Or maybe I?m wrong?!

hackulous,

I hadn?t heard about this algorithm but I sure will search for it in Google and see what comes up. Thank you.

i have seen an algo that claims to be faster than bresenham, although based on it.

its called frith 's algo.

it was hidden in a pile of demoscene resources and now its not online anymore. i had that on a harddrive... tha crashed some time ago. lesson: donttrust the internet! grab what you can when you can. make backups! i found it again somewhere, but without some comments. they said there was an asm version with a big speed increase. there was also an asm line drawing based on ADC and i think it was 1 instruction/pixel.the academic algos that everyone quotes are not necessarly the best ever crafted.

demomakers rule!

http://www.java-tutor.com/aufgaben/j/insel/additives/base/fcircle.txt

and yeah, i know its based on setpixel. i guess its up to you to make an vram-address- based algo out of this and/ of to convert to assembly... :)

From working at D-Wave Systems on quantum-computer-related stuff, I'm well aware that theoretical ideas quite often don't work nearly as well in practice. However, an algorithm is not its implementation. You can make implementations of Bresenham's algorithms that are much faster than coding them "straight up", but it's just a good implementation of the same algorithm. That said, Frith's algorithm does appear not to be Bresenham's circle algorithm, but it is in the general class of Bresenham curve-drawing algorithms because it uses a balance variable that causes one action when below zero and another when above zero. From the looks of it, it might or might not be much faster than Bresenham's circle algorithm once both are optimized. Also, one instruction per pixel is impossible unless you've got a horizontal line and do it with "rep movsd", because to have a loop that draws a line, you need at least two instructions to update x and y, one instruction to set the pixel value, and one instruction to jump back.

On a semi-related note, the code in fcircle.txt does use dangerous syntax for C/Java that may produce different execution from different compilers, namely using a prefix/postfix ++/-- operator on a variable that is used elsewhere in the line. Some compilers have the ++/-- executed in left-to-right order, some in right-to-left order, and some leave them until after everything else on the line has been evaluated, so I'm not sure which his code is assuming. In Java I think it's standardized to left-to-right, and both VC++ and GCC do something different. Try out "a += a++ + ++a + a;" or something else crazy like that to see the differences.

Edit: Sorry, my statement of "highly regarded as the fastest" is a gross generalization and shouldn't be given a lot of weight. It's just that it's hundreds of times faster than trying to use stuff with square roots or trigonometry.

However, an algorithm is not its implementation. You can make implementations of Bresenham's algorithms that are much faster than coding them "straight up", but it's just a good implementation of the same algorithm

mmy views quite differ.i see noabsolute differencebetween algo and implementation, no clear line. you could write an algo in C.youcould write an implementation in C. its just you further refine the code,thinking at how the machine will execute it.to my eyes,if you switch from setpixel-based to vram-based, youve just changed your algo, or at least refined.. because then vith vram you can do things you couldnt otherwise.

That said, Frith's algorithm does appear not to be Bresenham's circle algorithm

i seem to recall the original file said the algo had been designed while trrying to improve on bresenham. yes that doesnt mean its based onto it.

lso, one instruction per pixel is impossible unless you've got a horizontal line and do it with "rep movsd", because to have a loop that draws a line, you need at least two instructions to update x and y, one instruction to set the pixel value, and one instruction to jump back.

i suppose youre perfectly right and im wrong.:)it must have been 3 or 4 ops.

On a semi-related note, the code in fcircle.txt does use dangerous syntax for C/Java that may produce different execution from different compilers, namely using a prefix/postfix ++/-- operator on a variable that is used elsewhere in the line. Some compilers have the ++/-- executed in left-to-right order, some in right-to-left order, and some leave them until after everything else on the line has been evaluated, so I'm not sure which his code is assuming. In Java I think it's standardized to left-to-right, and both VC++ and GCC do something different. Try out "a += a++ + ++a + a;" or something else crazy like that to see the differences.

i also think thistype of coding quite sucks, its confusing for me. if on top of that its ambiguous even to compiler as you say, its not kewl at all. but sems experienced coders liked it back in the days.btw in the src it seems "&" means "&&" and ";=" means "!="

Edit: Sorry, my statement of "highly regarded as the fastest" is a gross generalization and shouldn't be given a lot of weight. It's just that it's hundreds of times faster than trying to use stuff with square roots or trigonometry.

I think it might be faster with the loop unrolled by octant, so with that in mind, the optimized function might be something like the following (assuming that the compiler does left-to-right evaluation of the prefix/postfix operators). If done with the single loop, all 8 buffer addresses would need to be calculated instead of just keeping track of one.

Working at D-Wave on co-op was really awesome. They've got their first big public demo sometime in January, February, or March 2007. It'll be the world's first demonstration of a quantum computer being used for practical problems, and also the world's first demonstration of a 16-qubit quantum computer. Check out http://dwave.wordpress.com/ for the latest. I was even fortunate enough to get to write one of the two applications they'll be demoing (the molecule comparison one). :D