Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!hp4nl!star.cs.vu.nl!mmblom
From: mmblom@cs.vu.nl (Marc Blom)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Fast 3d Graphics
Keywords: fast 3d optimizing assembly cycles
Message-ID: <9554@star.cs.vu.nl>
Date: 4 Apr 91 17:43:50 GMT
Article-I.D.: star.9554
References: <9529@star.cs.vu.nl> <1047@cbmger.UUCP> <20338@cbmvax.commodore.com>
Sender: news@cs.vu.nl
Lines: 79


 
rjc@geech.gnu.ai.mit.edu (Ray Cromwell) wrote:
> 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.
 
Nope, a lookup table won't do, i'm hoping to write a elite like space
game some day so i don't know how everything has to be rotated in advance.
 
> 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
 
The OS has everything to do with it !, profiling shows that 85 % of the time
is spend in the OS, since i'm only using AreaMove, AreaDraw, AreaEnd & SetAPen,
optimising my 3d-routines alone won't do me much good. I have to come up with
something faster to replace these OS calls.
 
>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
 
What I'm doing looks something like this:
 
loop {
  discard objects that are not inside sight-pyramid
  get sin/cos values for this object out of a large table
  loop {
    rotate normal of next surface
    discard surfaces with normal pointing the wrong way (ie. not to screen)
    loop {
      rotate next point (of this surface)
      put point in perspective
    } end loop
  } end loop
}end loop
Sort remaining surfaces (comparing average Z-coords, qsort,
                         only pointers are swapped)	
loop {
  Draw next surface    /* closest is drawn last */
} end loop
 
>  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.)
 
Love to hear from the one that posted this ! (or someone who has it)
 
 
peterk@cbmger.UUCP (Peter Kittel GERMANY) wrote:
>All I hear permanently is, use tables, tables, tables instead of real
>(or integer) calculations. At least for the sin and cos calculations.
>Estimations about real-life situations show that you don't need tremendous
>precision normally (but that depends on your real project). Perhaps even
>2D or 3D rotations could be simplified into one (more or less) big table.
>It's worth considering in any case.
 
I wish I knew how to use tables without taking too much memory: I'm using
360 degrees around each angle, so to multiply a coordinate with a sin/cos
(this is one table) value i would need 360 words PER coordinate, I'm now
using coordinates that range from -16K to + 16K. I don't even want to
calculate this ! (22.5 meg !) Offcourse i could use less percision, for
instance only rotating by an even number of degrees (0,2,4...,360) and
don't use such a large a coordinate system, but i don't want to compromise
between speed/presicion just yet !
 
+--------------------------------------------+------------------------+
| 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 ! |
+------------------+-------------------------+------------------------+