Star Flight
Volume Number: 2
Issue Number: 3
Column Tag: Pascal Procedures
Star Flight Graphics in TML Pascal 
By Mike Morton, InfoCom, Cambridge, MA
Mike Morton wins $50 for the outstanding program of the month with this
feature article. Congratulations Mike!
Star Flight: Real-time, 3-D animation on the Mac
In the fall of 1984, I made the mistake of watching too much of a nine-hour
“Twilight Zone” extravaganza. Most of that night was a blur, but I remembered one
scene vividly -- flying through space fast enough that the stars whizzed by. Today this
effect is commonplace, appearing in everything from “Nightline” credits to “Star
Trek” reruns. But it's usually done with expensive equipment and filmed one frame at
a time. I wondered if a Macintosh could do the same thing in real time. The result is
an exercise in simple 3-D graphics and optimizing a Macintosh program.
This article explains the program “Small Flight”, a subset of “Star Flight”
(available through the Boston Computer Society's Mac group, or on the MacTutor source
code disk #7). The reduced version is missing speed controls and special effects, but
incorporates all the important internals of the original program.
Perspective 3-D graphics:
“Small Flight” keeps track of star positions in a 3-dimensional space; each star
has X, Y, and Z coordinates. The viewer looking at the Mac screen is looking along the Z
axis in the positive direction. To simplify things, flying through space is done by
decreasing the Z coordinate of each star, not increasing the viewer's Z coordinate. Thus
the viewer is always at the origin.
Where does the star at the 3-D point (X, Y, Z) appear on the screen? To find the
location (h, v) on the screen, the formulas are:
h = X * k / Z
v = Y * k / Z
“k” is a constant which determines how wide the view is. I used the maximum
value of Z for k, and got a reasonable view. Try adding a control to vary k to see how it
affects things.
[For a more detailed explanation of perspective graphics, see Foley and Van
Dam's classic Fundamentals of Interactive Computer Graphics. The above formulas are
from chapter 8. You can derive them with a few sketches, using similar triangles.]
Implementation -- the “star” data structure
A star needs very little information. At a minimum, its 3-D location (X, Y, Z)
needs to be kept. “Small Flight” keeps X and Y in a Quickdraw point, and Z separately.
The screen location is also kept when the star is first drawn, so it doesn't need to be
recomputed when the star is erased.
To initialize the data structure, the procedure “makestar” picks random values
for X and Y, within a range. It always starts with the maximum value for Z. Then it
derives the initial screen location and draws the star there.
Implementation -- moving a star
The main loop repeatedly calls the “cycle” procedure to move every star. This
routine loops through the array of records and processes each one.
A given star is always erased, then its new position is computed. If the new Z
coordinate is less than zero, the star is too close to see and a new random values are
stored in that star's record. If the computed screen location is outside the view
rectangle, the star is also out of sight and a new star is generated.
Stars are always drawn as single pixels; this is done without Quickdraw. The
program would be much slower using Quickdraw; I'm indebted to Dave Pearson of True
Basic for suggesting the technique which is used instead. A 68000 procedure “flippix”
is passed the screen coordinates and toggles the bit in memory which corresponds to
that point on the screen. The only complication is making sure the cursor doesn't
interfere: the routine temporarily hides the cursor if it would be in the way, just as
Quickdraw does.
Optimizations in Star Flight
Star Flight has lots of tricks to try to speed up the program, allowing more stars
to be animated, but keeping the animation running fast enough to fool the eye. To make
“Small Flight” presentable for educational purposes, I ripped out most of the tricks.
To my embarrassment, the speed difference was nearly nil. Some speedups from both
versions are worth describing:
• the calculations for perspective were originally precomputed and stored in an
array. This doesn't actually speed things up much, and slows down initialization a
lot. It also limits the maximum X, Y, and Z values since arrays are limited in
size.
• since the Random function is expensive, I called it just once in the original
“makeStar” and sliced up the result to get two random numbers.
• since “cycle” repeatedly refers to “stars[i]”, it creates a pointer to the i'th
star and avoids a lot of subscripting.
• the code in “cycle” which checks if the star is outside the bounds rectangle could
be done with a call to “PtInRect”, but the explicit checks are faster.
• avoiding Quickdraw is the most important optimization. Try removing calls to
“flippix” and use “InvertRect” instead; see how much slower it gets!
Enhancements in “Star Flight”
The user interface which allows you to control the speed in the real “Star
Flight” is easy to do. The menu commands just vary the variable “speed” (which is a
constant in the scaled-down version). The only fancy thing is “warp” mode, in which
stars leave trails; it's just a flag which pr events stars from being erased. Try adding
your own controls to the program; perhaps graphical ones would be better than the
menus in “Star Flight”?
Some projects you might consider:
• make the stars cover the display uniformly, instead of clustering at the center.
In a real spaceship, the density should be the same in any direction.
• similarly, avoid the “waves” of stars which occur in the first moments of flight.
• when you leave “warp” on for a while in “Star Flight”, patterns appear on the
screen. I think this is because the 3-D coordinates have such a small set of
discrete values. Try using larger values, but be careful not to overflow 16 bits
in your calculations of screen location!
• because the program makes no effort to keep in sync with the hardware screen
refresh, you can sometimes see stars “twinkle”. This is because the star is
erased from memory and the screen is refreshed before the new location can be
drawn in memory. This is more apparent when the star is moving upwards, since
the refresh sweeps downwards. You could minimize this effect with a modified
“flippix” which toggles two points, hoping to erase and redraw with as little time
as possible in between.
• to get smoother animation, you might try using the alternate video buffer.
Of course, there are a lot of other changes. Add better navigation -- roll, pitch,
and yaw. Have the apparent size of a star change as it approaches! Introduce comets
which don't move in a simple path. Add Klingons and photon torpedoes add a network
hookup for multiple players have fun!
Putting It All Together
by David E. Smith
Small flight is written in TML Pascal, which is practically 100% Lisa Pascal
compatible. The Pascal source may be compiled into a ".REL" file format or into
assembly source code to be compiled by the MDS assembler. To get the Pascal to compile
correctly under HFS, the include files and the source code file must reside in the same
folder and on the same disk as the compiler. Version 1.1 of TML Pascal will fix some of
these HFS dependencies and may be updated for $20 by contacting Tom Leonard directly.
As is my practice, I compiled the pascal source into assembly source code, and then
switched over to MDS to complete linking the code. [Note that you don't have to do it this
way; I just prefer it.]
The FlipPix routine is an assembly routine which flips the pixel on the screen to
draw and erase the star directly. This routine could be very useful in a variety of
applications where direct screen updating in assembly is required. Note that provision
is made for the cursor! This routine is written in MDS assembly and is assembled by
moving the assembly source code and all the include files to the same disk as the
assembler, in the root directory (ie not in any folders). Again these HFS bugs are being
fixed by Bill Duvall of Consulair, who is doing the update to MDS for Apple and which
should be ready in April. In the meantime, Bill has released version 4.52 of his smart
linker and C system, which includes a fixed version of the editor and linker for HFS.
Contact Consulair Corp. about updating the C package to version 4.52, and you will also
gain an improved editor and linker for HFS that will work with TML Pascal. It is likely
that Tom and Bill will cross license their two products so they can be sold as a
compatible development system in the future; a marketing move we encourage both
companies to adopt. In the meantime, they remain separate but equal in compatibility.
The linker has the most problems under HFS. It won't recognize it's own link
file! To get around this, click on the linker and then shift-click on the link file and
select open from the file menu. This will start the link process. Then remember, again
to have all the ".REL" files together on the same disk as the linker and not in any
folders. Then the link process should proceed normally.
The resource file is a simple assembly file that provides the basic Finder
information to make a custom icon pop up on the desktop. You can create an icon with
the icon editor and convert it to an "include" file by running Chris Yerga's icon
converter program on it. Or you can use a DA called Icon Maker to create the hex code
for the icon, or an icon resource directly.
The link file combines the code files for the Pascal program, the FipPix
assembly code, and the compiled resource file into a runnable application with the
appropriate file attributes set to create the custom icon. The TML Pascal creates an
initial link file for you that you can then edit depending on what your doing. In this
case, we edited TML's link file to include the FlipPix assembly routine. Note that unlike
Microsoft's Fortran, the TML run time pacakge is fully MDS compatible! (We encourage
Microsoft to fix up their buggy Fortran version 2.1 and make it fully toolbox and MDS
compatible.) We continue to push for the MDS ".REL" file format as a standard which
currently supports the MDS assembler, the Consulair C and TML Pascal as all linkable
under the same linker, with Fortran almost there. That makes a considerable
development system which we feel is the best way to go at the present time. It is our
hope that other companies will work to establish a linking standard with these compiler
products.
program smallflight; { a scaled-down "star flight" }
{ Written by Mike Morton for MacTutor }
{ Converted to TML Pascal by David E. Smith}
{$I MemTypes.ipas} { TML Mac Iibraries }
{$I QuickDraw.ipas} { Quickdraw interface }
{$I OSIntf.ipas } { Operating System interface }
{$I ToolIntf.ipas } { Toolbox interface }
const
numStars = 140; { number of stars we display }
maxXY = 64; { largest star radius (X or Y) }
maxZ = 200; { largest star distance (Z) }
speed = 4; { Z change per animation cycle }
star = record { information about one star }
ploc: point; { physical location in space (X, Y) }
z: integer; { physical location in space (Z) }
sloc: point; { location on the screen (h, v) }
end;