Xref: utzoo rec.games.programmer:3490 comp.os.msdos.programmer:4839 comp.graphics:17425
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!dog.ee.lbl.gov!nosc!crash!jcs
From: jcs@crash.cts.com (John Schultz)
Newsgroups: rec.games.programmer,comp.os.msdos.programmer,comp.graphics
Subject: Re: Need hard core help doing some 3d optimizations
Message-ID: <8742@crash.cts.com>
Date: 23 Apr 91 01:24:30 GMT
References: <1991Apr13.154112.11345@dircon.co.uk> <1991Apr16.210819.17873@cs.fau.edu> <1991Apr17.133142.24149@maytag.waterloo.edu> <1991Apr17.235954.2334@cs.fau.edu>
Organization: Crash TimeSharing, El Cajon, CA
Lines: 22

In <1991Apr17.235954.2334@cs.fau.edu> conners@cs.fau.edu (Sean Conner) writes:

[stuff deleted]

>  So, we have the 386/387 covered.  What about the 68020/68881(2)?  I have
>an Amiga at home :-)

  With the 68020/030/881/882 fixed point is much faster. Previous posts on
this topic only considered mul and div (?). Add and sub are *very* slow for
floats (slower than muls), whereas for ints, add is very fast. The best way to
check the speed difference in methods is to write two versions of a function,
one using floats, the other using ints, then compare times. If you mix
floats with ints on the 680x0/88x, you'll see some speed penalties for
processor to coprocessor moves (around 107 cycles in some cases). With
32 bit / 64 bit intermediate ints, you should be able to handle all computer
graphics math. Physics equations are a different story... Anyway, with
an assembler such as Adapt, you can dissassemble your code and compare
instruction cycle times for various methods. The only way to know for sure
it to time both methods and compare.


  John