Xref: utzoo rec.games.programmer:3340 alt.msdos.programmer:2529 comp.os.msdos.programmer:4495
Path: utzoo!utgpu!cs.utexas.edu!sdd.hp.com!think.com!mintaka!ogicse!milton!uw-beaver!cornell!ressler
From: ressler@CS.Cornell.EDU (Gene Ressler)
Newsgroups: rec.games.programmer,alt.msdos.programmer,comp.os.msdos.programmer
Subject: Re: 3D Rotation
Message-ID: <1991Apr6.230454.20408@cs.cornell.edu>
Date: 6 Apr 91 23:04:54 GMT
References: <1991Apr05.224711.12750@lynx.CS.ORST.EDU> <1991Apr5.201714.29494@kuhub.cc.ukans.edu>
Sender: news@cs.cornell.edu (USENET news user)
Followup-To: ressler@cs.cornell.edu
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Lines: 49
Nntp-Posting-Host: turing1.cs.cornell.edu

In article <1991Apr5.201714.29494@kuhub.cc.ukans.edu> 2fmlcalls@kuhub.cc.ukans.edu writes:

>In article <1991Apr05.224711.12750@lynx.CS.ORST.EDU>, murrayk@prism.CS.ORST.EDU writes:
>
>Well, this atleast is how I've done it.  Perhaps someone knows of an even
>quicker method [for doing view transforms]?
>
>john calhoun

If you're into speed, there was an old Byte (~84) that
had a rough but useful article for doing a full view transform
(translate eye point to origin, rotate, scale, and optionally apply
planar OR concentric (spherical) perspective _transformation_ so
you could still do hidden surface removal).  They had fudged the
whole deal into integers, so the `world' coordinates could be
anything -32768 to 32767 (almost; this was the rough part) and
the view transform was in assembly language that used 16 bit
multiply and divide only as necessary to get pretty good
approximate images (there were some view angles where overflow could
be arbitrarily bad with their math, but a careful reprogramming
got around these).  Anyway, the code was in the article; again rough but
usable.

The reason I remember this is that I fiddled with it for a bit.
The code easily interfaced to good old DeSmet C. (This was before DOS 2.0!)
Sorry I can't retrieve the article or its date. Anyone else remember?

With my 4.77Mhz 8088, it could transform about a 1000
points a second.  I'm certain a 486 could approach 100 times this.
Actually another guy and I made a project out of building an add-in
board with another 8088 scan converting lines, so with both processors
running full blast we could get images of a few hundred vectors
animated at about 2 frames a second; not much these days, but great fun
at the time.

Also, there are neat tricks if you're willing to accept orthographic
(not perspective) projections and other special cases.  For instance,
there is an almost trivial hidden surface algorithm for ``floating
fishnet'' f(x,y) plots.  I've got TP/asm code that, given an
array of 21x21 values, displays a 20x20 square grid that can
be rotated under cursor control at about 3 frames/sec including hidden
surface removal (on an 8Mhz 80286).  It does a little prestorage of
transformation parameters, but no where near entire images.
I suppose I could post it somewhere if there's interest.

Sorry for rambling.  You can probably tell that squeezing descent 3d
graphics performance from marginal hardware is somewhat of a hobby.

Gene Ressler