From oleg Wed Jul 20 08:53:09 CDT 1994
Newsgroups: rec.games.programmer,comp.lang.c++,comp.sys.mac.games
Subject: Simple virtual reality thing - flight thru clouds (w/ C++ source)
Summary: announcement of upload of a simple VR appl with C++ source
Followup-To: 
Distribution: 
Organization: University of North Texas, Denton
Keywords: virtual reality, 3D rendering, C++ source
Cc: 
Status: RO

Some time ago Tim Clarke (tjc1005@hermes.cam.ac.uk) described the guts
of his program of generating Marsian-like landscapes and flying over
them. The program MARS.EXE was really cool! The article in
rec.games.programmer was very inspirational, too, so I took on making
my own program. I used nothing but the article (caveat: there were a
few typos in it), and derived and implemented the algorithm almost
from scratch.

The C++ source code and the executable (for Mac) is archived at
standard places (info-mac,
ftp://sumex-aim.stanford.edu/info-mac/games/flight-thru-clouds.hqx,
ftp://sumex-aim.stanford.edu/info-mac/dev/src/flight-thru-clouds-cpp.hqx
(source), and mirrors of info-mac at wu-archive
(ftp.wustl.edu:/systems/mac/info-mac) and other sites).

The program is written in C++ (with a clear separation between 3D
rendering and messing with the Mac GUI), so it's rather portable. And
of course, it's easier to get a hang on the technique from a C++
source than from an Assembly. I've ported the program into X Windows
(using XVT: a platform-independent GUI builder).

The source is (way too) well commented. Source file 'project_3D.cc'
contains the fullest description (I could come up with: 100+ lines of
comments) of the 3D rendering technique: with the background
explanation, equations, pseudocode and the actual code (and tricks
with the fixed-point arithmetics: hey, no floating-point numbers are
in here).

The executable is bigger than that of Tim's, partly because drawing in
a Mac window requires a bit more care (than just seizing the VRAM
entirely for myself, which is a common PC strategy), and because there
is too much extra fat. Say, once printf() is referenced somewhere in
the code, even if it's not used at all, it drags in the entire I/O
package with it, and that's a lot! But the object code for the two
main modules, FractalMap.cc and project_3D.cc is under 7K (which is
comparable with Tim's 5K. And hey, it's not an assembly, it's C++!).

I tried to optimize the program as much as I could without sacrificing
generality too much. I could've used the fact that the dimension of
the image, say, is 128.  Then I could've written clipping like
	y_map = y & 127
instead of (I hope more obvious)
	y_map = y % map.q_nrows()
Well, in the latter case, if I'm sure (and I'm) that y is non-negative
and by itself is no bigger than 2*map.q_nrows(), I'd rather use
	if( (y_map = y) >= map.q_nrows() ) y_map -= map.q_nrows();
You know, subtraction is faster than division (or taking modulo for that
matter). Yet, the logical AND is faster.

BTW, how do you like the following quirk?

>  OneViewScanline * curr_scanline = &scanline1,
>                  * prev_scanline = &scanline2;
>                                        // note curr_scanline ^ pointer_diff
>                                        // gives prev_scanline, and
>                                        // vice versa
>  int pointer_diff = (long int)curr_scanline ^ (long int)prev_scanline;
>	............
>                                        // exchange pointers
>  (long int&)curr_scanline ^= pointer_diff;
>  (long int&)prev_scanline ^= pointer_diff;

Although casts to different pointer types are frequent, I haven't come
across (very often) casts to a reference. I need it here to get an
l-value. BTW, GCC chews it up, but Symantec C++ (after 7.0.1)
chokes...  (internal compiler error). Well, GCC dies on some
declaration of nested classes (again, internal compiler error, do I
hate it! <sigh>)

If you need further information or details, or have comments, please
mail me at oleg@ponder.csci.unt.edu or oleg@unt.edu