A circle does have infinitely many axes of symmetry. But when drawing one, we make use of the vertical, horizontal and 45-degree diagonal axes. Thus our pixellated approximation will be symmetrical in these axes (and almost symmetrical in the other axes).

Goodbytes, the distance comparison is just Pythagoras's Theorem. Square the x and y offsets (the coordinates of the point minus the coordinates of the centre of the circle), add the squares together, and compare this with a squared version of the radius. You can then potentially optimise this by making use of the last value of x*x and y*y, e.g. when x is incremented you can take advantage of the following identity:

(x+1)*(x+1) = x*x + 2*x + 1

And thus you can modify 'x2', your squared x value, as follows:

x2 += 2*x + 1;

This may or may not be quicker than just recomputing x*x; it would depend on the processor architecture. However, taking advantage of old values of y² would almost certainly help because y will not always change.

Google for "Bresenham circle algorithm", or "midpoint circle algorithm" (they're not quite the same, but they both reduce to just adds/subtracts/shifts).

most importantly:

if (df < 0)  {
   df += d_e;
   d_e += 2;
   d_se += 2;
      }
      else { 
   df += d_se;
   d_e += 2;
   d_se += 4;
   cy--;
      } 

      cx++;

insanely simple...yet so very very complex

just out of interest I found once that you can draw a circle using square root only instead of sin / cos (can't remember the situation - I think it was with atari basic!).

this is due to the fact that in the fig below the #'s are right angles, so if you know the diameter D and distant X you can find Y because 2 triangles are formed that share dimensions, so the result can be found using pythag.... can't remember the formula though but it's a nice little puzzle for those on their lunch breaks.

      **
    #*     **
   *| \      *
  *||  \      *
 *| |    \     *
 *| | Y   \     *
*|  |       \   *
*|  |         \ *
*---#---o-------*
  X     D

Edit: hah (I think)
y = sqrt( (x^2+(d-X)^2)/2)

So do you guys think that you could use that circle drawing thing to approximate sin and cos values? I mean, if you can draw an approximated circle with sin and cos values, could you reverse the process, and instead use that circle to calculate sin and cos values? I'm writing a game with alot of rotation, and that would be sweet. Sure, I could use lookup tables, or a fixed point system, but that way would be cool too. As long as you don't have to add like a thousand things to get to the right point to calculate sin and cos.

The 'pixel walk' method used in drawing a circle will use points on the circle's circumference, but the rate of change of the angle will not be constant or predictable. Sorry, you can't replace sin and cos this way.

Evert, you do realize i'm talking about the human mind, right? and not a machine? It's harder for our minds to do decimal compared to integers, unless you've studied decimal math in your head extensively. Calculator and computer wise, duh of course decimals are fine, but I was talking about why we use degrees so much, cause we can do the calcs in our heads a lot.

i.e.
x - pi/2
is harder to calculate in our heads than
x - 90

And since we're the ones programming the computer, they have to follow suit

Anyway, the more you use radians, though, the better.

BTW, as for optimizing sin&cos: They actually aren't too bad. From Bob's exext.c code I came up with the Taylor Series(?) and this:
sin(x) = x - (x^3)/3! + (x^5)/5! - (x^7)/7! ... (x^b)/b!
where b is some odd number depending on your accuracy. Bob only went up to 7 and multipled the input by .98 to compensate for the inaccuracy. For calculator accuracy(10 digits) you need to go up to ~15, but 4 and the "fudging" should be accurate enough, so really the calculation is only: ~10 operations + the shift to the [-pi, pi] period. It really isn't as bad as you would think, especially sine trig functions are actually implemented on the CPU as a single OPCode(i.e. there is likely some more optimizations that can be done on the bit level). The problem really comes from the usage of floats(unavoidable, and yet floats are becoming faster as well) and calling the function excessively.

eDIT: Whoopsie

Not really ten operation.

For

sin(x) = x - (x^3)/3! + (x^5)/5! - (x^7)/7!

you need to write

sin(x) = x- (x*x*x*)/(3*2) + (x*x*x*x*x)/(5*4*3*2) + (x*x*x*x*x*x*x)/(7*6*5*4*3*2)

The good way is to calculate this in a loop, so you can reuse previous results.

WH: doh!, I might of known it would simplify more than that, should have googled before posting, smacks head. If only I had google and an education in 1983!.
I'll bet there's a (a^2 - b^2) = (a + b)(a - b) simplification in the proof somewhere ... never trusted that since I learned that you can prove that a = -a with it (but that's a bit off topic for this thread I suppose )

The proof is invalid. To the best of my recollection, it uses a step like the following:

0*2 = 0*3
therefore 2 = 3

You are only proving that a = -a after having established that a = 0. It's something along those lines anyway. If you post the proof I'll comment specifically on how it's invalid.

Ahh yes, area calculations are much easier with radians, sure. But I'm pretty sure that for most of your childhood you used degrees, cause they really don't teach radians until pre-calc. Afterwards, yes, it is quite possible that you adapted to radians just fine and use them.

Um, 0/0 isn't defined, is it?

Marcello

It is defined. Its defined to throw an exception. (SIGFPE)