Peter L. Peres wrote: > On Wed, 4 Nov 1998, Ben Stragnell wrote: > > > Peter L. Peres wrote: > > > > > My idea is, that since the Bresenham circle algorythm exists, it is > > > possible to compute the 'next' value for a phase continuous sine wave > > > without storing any table and by obtaining results directly in integers > > > (no floats no lookups no nothing). > > > > Ok... Bresenham will get you the appropriate X coordinate for iterative > > steps in Y (or vice versa), but then all you have is a pair of > > coordinates. How are you going to convert those into sines? If I > > The coordinates (one of them) IS the sine corrsponding to that cosine, and > vice versa. I suppose that one could turn the algorythm a little bit to > yield a true sine or cosine, or, use the ellipsis algorythm (by Bresenham) > to approximate the sine using a linear increment. Remains to be seen how > accurate this can be made. Trouble is, even though you're given both the sine and cosine of an angle, I don't think there's an easy (ie. trivial and PICable) method of knowing what that angle is, much less of stepping though the algorithm with fixed angular increments. I'm not sure about the ellipse algorithm, but I think if you try to approximate the sine function using the linear steps along an axis that Bresenham gives (as opposed to a fixed angular increment), you'll wind up approximating the sine function with straight lines from sin(-45 to 45), and quarter circles from (sin 45 to 135) (the tops and bottoms of the curves). Of course this may be a good enough approximation for DTMF, and other applications, but it's definately not a pure tone. You could always look into simple harmonic motion - keeping track of a point's position and velocity, and then using position to derive the acceleration each tick would yield a nice pure sine wave if you get the scalings right. sin''(t) = -sin(t). Trouble is, to make the frequency adjustable without breaking the amplitude would probably require a whole nasty bunch of multiplies. Ouch :) Cheers, Ben