Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!van-bc!mdivax1!mclaren
Newsgroups: comp.sys.amiga.tech
Subject: Re: Integer sine calculations?
Summary: Not sines at all, just arithmetic
Keywords: assembly integer sine
Message-ID: <1990Nov21.221825.10898@mdivax1.uucp>
Date: 21 Nov 90 22:18:25 GMT
References: <7336@hub.ucsb.edu>
Reply-To: mdivax1!mclaren (Gavin McLaren)
Distribution: comp
Organization: Mobile Data International, Richmond, B.C., Canada
Lines: 53
Return-Path: <mdivax1!news>
Apparently-To: van-bc!rnews

In article <7336@hub.ucsb.edu> 6600mage@ucsbuxa.ucsb.edu (Orion Wilson the Passable) writes:
>	.. Have you seen these hacker demos where
>the balls or whatever follow sinusoidal paths around
>the screen? And where there are HUNDREDS of balls
>all going very smoothly through what appear to be
>complex hypo-cycloids and such?  
>My question is how these paths are computed. The
>number of objects and their speed incidates that
>they aren't being done by floating-point techniques,
>and i'm pretty sure the numbers are not
>pre-calculated, so it seems that smooth curves like
>the sin and cos can be done using integer (native
>MC68000) arithmatic.

Well, I can't speak for the second example, with hypo-cycloid path, but
the standard balls demos don't have to involve trig functions at all.

These demos start with a ball(s) at the bottom of the screen.  Then, the
position relative to the screen bottom is calculated using the formula

y = (ay * t * t)/2 + vy * t + ystart

t is the iteration number, which increases at a specified interval.
ay is initial acceleration
vy is initial velocity.
ystart is the initial position

Now acceleration is a constant, as is the initial position.  These demos
provide the illusion of random motion by resetting the equation (t = 0) and
giving a random upward velocity when the position == ystart (or is below ystart)

There is also horizontal morement, usually calculated as

x = (ax * t * t) / 2 + vx * t + xstart

ax is usually zero, since gravity does not intuitively operate sideways.

judicious selection of the constants can even obviate the need to convert
the results back into screen coordinates.  IE. make ystart the bottom of the
screen, positive acceleration, negative initial velocity.

Of cource, enhancements allow balls to either bounce off of the sides of the
screen, or wrap around.  Some algorithms convert the equations into 
incremental additions, which has to keep track of current position and velocity
and incrementally change both every iteration.  This saves multiplications
and operates faster (but there are more errors in cumulative roundoff).

Now the bad news is that I don't know for sure.  The two equations could
be rewritten for polar coordinates, and thus use sines and cosines, but I'm
not sure this would be a good use of anyone's time. :)

--Gavin McLaren
...!uunet!van-bc!mdivax1!mclaren