Newsgroups: comp.sys.amiga.programmer
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!geech.gnu.ai.mit.edu!rjc
From: rjc@geech.gnu.ai.mit.edu (Ray Cromwell)
Subject: Re: Fast 3d Graphics
Message-ID: <1991Apr3.085847.14287@mintaka.lcs.mit.edu>
Keywords: fast 3d optimizing assembly cycles
Sender: news@mintaka.lcs.mit.edu
Organization: The Internet
References: <9529@star.cs.vu.nl>
Date: Wed, 3 Apr 91 08:58:47 GMT
Lines: 87

In article <9529@star.cs.vu.nl> mmblom@cs.vu.nl (Marc Blom) writes:
>'m wondering how fast 3D graphics can really go. I've written some rotation
>and perspective routines (in assembly) and profiling shows that 60 % of the
>time is spend in my routine RotatePoint. This routine rotates 1 point around
>all three axes in only about 900 cycles minimum and about 1100 cycles maximum.
>Is this fast ? Can someone do better ? (If so PLEASE mail me how you did it).
>I won't include the source here because it's about 100 lines long but instead
>i'll tell you what it does: It rotates a point x.word, y.word, z.word (signed)
>using fixed point (14 bits behind the point) integer calculation. rotating
>around each ax uses 4 muls, giving a total of 12 muls. (This is the variation
>in clock cycles I mentioned above, about 900 for best case muls, about 1100
>for worst case muls) By the way, these clock cycles are only valid for a plain
>68000. (I don't know about 680x0 with x=1,2,3,(4?) I believe you then have to
>play with cache-sizes etc. to get the best results).
>I want to have the fastest possible rotation routine so I can concentrate on
>kicking the Graphics Library AreaMove/Draw/End out (In a system friendly manner,
>don't worry :-) ) And write a fast blitter routine.
>The 60 % mentioned above was only relative to my routines part of the execution
>time, of the total time involved, 15 % was spend in my routines, including
>RotatePoint, Perspective etc and 85 % was consumed by those wonderfull (yuk,
>did I say wonderfull ?) Graphics Library Calls. No wonder games writers kick
>the OS out ! (I hope this doesn't provoke another TO OS OR NOT TO OS
>discussion !)
>If someone is interested in the source of RotatePoint, just drop me a line and
>I will mail it to you.
> 
>	Marc Blom
> 
>+--------------------------------------------+------------------------+
>| Marc Blom        | Email: mmblom@cs.vu.nl  | What IS the question ? |
>| Gondel 14/13     |                         |                        |
>| 8243 BL Lelystad | Phone: 03200-46233 (NL) | TO OS OR NOT TO OS,    |
>| The Netherlands  |                         | that is the question ! |
>+------------------+-------------------------+------------------------+
> 

 Well, this all depends on what you are trying to do. Do you want to do
a flight simulator, or are you doing an animation/demo/model rotation?
If the latter, you can precompute all the rotations before run time, and
just render them via lookup table.

 As for the OS, it really has nothing to do with your project. What needs
to be optimized is the critical section of your rotation routine. I'd suggest
caching the points and computing all the rotations first, then render
them later all at once. I have the feeling you're doing something like this:

loop {
  calculate point
  render point
  get next point
} end loop

 You should (IHMO) calculate all the pointers first, and if space
isn't a problem, unwind the loop and use lots of lookup tables. You can
also add in special case optimization for known rotations like 0, 45  and 90
degrees. 

 As for rendering, you don't need to kick out the OS. Just raise your
priority, OwnBlitter, and render all the points.

 The procedure looks like this:

start
  calculate points
  OwnBlitter()
  render points
  DisownBlitter()
loop to start

  This is friendly because while you are calculating (not using the blitter)
other programs can use the blitter. Of course Mike and the other
'kill the OS' people will suggest that you Disable() all interupts
and do your calculations while the blitter is running in parallel.
This is fine if you doing a game, but if it's something like a 3d modeler
I'd advise against it. Owning the blitter for long periods of time is
very unfriendly.

  I seem to recall someone posted a 'really fast' line drawing 
routine a while back. It was highly optmized for speed using the
CPU (not the blitter. It also was very long because loops were unrolled
and it had lots of special cases for different line slopes.)

--
/~\_______________________________________________________________________/~\
|n|   rjc@albert.ai.mit.edu   Amiga, the computer for the creative mind.  |n|
|~|                                .-. .-.                                |~|
|_|________________________________| |_| |________________________________|_|