🚀 go-pugleaf

In article <20298@plains.NoDak.edu> tscott@plains.NoDak.edu (Timothy E Scott) writes:
>1) Created two 180 element arrays sine and cosine, which are
>   equal to the sine/cosine of an angle times 10000.  Any
>   references to an angles sine/cosine therefore are not
>   computed.

It should be faster to make the multiplier a power of 2.  Either
16384 or 8192 would be good.  That way, you can use a right shift
instead of a divide. 

A little bit of assembly would help out a lot, since many compilers
(BC++ for example) do a function call for every operation on a long.
It is annoying to do assembly code using 16 bit registers for 
operations on longs, but it is pretty simple, and you don't need to
learn much assembly.  

>3) The points to moveto and drawto (as I named the procedures)
>   are stored in memory and referenced through the use of a
>   pointer.  I have no idea if this improves performance or not,
>   but it seemed 'like the right thing to do.' :)

You might want to consider using polylines.  A polyline is just something
like this:

typedef struct
  {
  int  x,y,z;
  } point;

typedef struct
  {
  int  length;
  point *points;
  } polyline;

Then you just pass a pointer to the polyline to your draw_polyline()
which connects all of the points with a line.
(actually this probably won't improve speed, but it makes it a bit easier
to program)

If you have access to a profiler, use it.  You will probably find that
clearing the screen between frames (if you do that) takes a huge chunk
of the time.  The other big things would be the part of the code that
actually draws pixels to the screen and the bit that does the transformations.

----
"Dwayne Dibly?!" - The Cat (I've seen 5th season.  Have you?)
----