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 prevents 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 }
type
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;
var { global program variables }
stars: array [0..numStars] of star; { information on stars }
bounds: rect; { rectangle used for bounds checking }
sorigin: point; { center of screen }
myPort: grafPort; { our graphics environment }
anevent: eventrecord; { for checking if the user's bored }
procedure flipPix (h, v: integer); external;
{ asm routine to flip pixel }
{ makestar -- randomize physical location; set Z and }
{ find screen location. }
procedure makeStar (VAR new: star); { initialize one star }
var dh, dv: integer; { star's position, relative to origin }
begin;
new.ploc.h := random mod maxXY; { horizontal position }
new.ploc.v := random mod maxXY; { vertical position }
new.z := maxZ; { how far away is it? }
dh := new.ploc.h*maxZ div new.z; { compute h offset }
new.sloc.h := sorigin.h + dh; { compute absolute h pos }
dv := new.ploc.v*maxZ div new.z; { compute v offset }
new.sloc.v := sorigin.v + dv; { compute absolute v pos }
flipPix (new.sloc.h, new.sloc.v); { flip spot (draw star 1st )
}
end; { of procedure makeStar }
{ initialize -- Do Mac initializations; calculate display rect; init
}
{ screen; define bounds rect; draw initial stars. }
procedure initialize; { one-time initialization }
var i: integer;{ star number }
begin;
initGraf(@thePort); { fire up quickdraw }
openPort(@myPort); { get a drawing environment }
initCursor; { get rid of the Finder's "watch" }
bounds := screenbits.bounds; { start with whole screen }
insetRect (bounds, 25, 30); { shrink it in a bit }
sorigin.h := (bounds.left + bounds.right) div 2; { find the... }
sorigin.v := (bounds.top + bounds.bottom) div 2; { ...origin }
eraseRect (myPort.portRect); { clean the screen }
invertRect (bounds); { space is black }
offsetrect (bounds, -sorigin.h, -sorigin.v);
{ center bounds on origin }
for i := 1 to numStars do { loop through all the stars..
}
makeStar (stars [i]); { ...and make up each one }
end; { procedure init }
{ cycle -- main routine. For each star, erase the old position.}
{ See if its motion has carried it past the plane we're in. If so,
}
{ we create a new star. If not, we compute the new apparent }
{ position from the new Z.If the apparent position is outside }
{ display, we create a new star; otherwise we draw the star's }
{ new position. }
procedure cycle; { do one animation cycle }
var
i: integer; { star number in main loop }
dv, dh: integer; { star coordinates, origin-relative }
sp: ^star; { fast pointer to stars[i] }
begin;
for i := 1 to numStars do { loop through all the stars }
begin;
sp := @stars[i]; { point to star (avoid subscripting) }
flipPix (sp^.sloc.h, sp^.sloc.v);
{ erase the star's old position }
sp^.z := sp^.z - speed;
{ time advances: find new z position }
if sp^.z <= 0 { past the plane of the eye yet? }
then makeStar (sp^) { yes: this star's gone; make another }
else begin; { no: update star's screen position }
dh := sp^.ploc.h*maxZ div sp^.z; { compute relative h }
sp^.sloc.h := sorigin.h + dh;
{ and compute absolute screen h }
dv := sp^.ploc.v*maxZ div sp^.z; { compute relative v }
sp^.sloc.v := sorigin.v + dv;
{ and compute absolute screen v }
if (dv >= bounds.bottom) { is the new position... }
or (dv <= bounds.top) { ...outside... }
or (dh >= bounds.right) { ...the bounds rectangle...
}
or (dh <= bounds.left) { ...which is centered at origin?
}
then makeStar (sp^) { yes, so get a new one }
else flipPix (sp^.sloc.h, sp^.sloc.v)
{ no: draw it at new position }
end;{ of case where z didn't go off edge }
end;{ of loop through all stars }
end; { of procedure cycle }
begin;{ main program }
initialize; { set everything up }
flushEvents (everyevent, 0); { ignore stale events }
repeat { main loop: }
cycle; { do one animation "frame" }
until getnextevent (mDownMask+keyDownMask,anevent);
{ until click or key }
end.
;
; flippix -- complement a pixel on the screen, given its
; global coordinates.
;
; procedure flipPix (h, v: integer); external;
;
;Written by Mike Morton for MacTutor
;Converted to MDS Assembly by David E. Smith
;
;
xdef flipPix
include QuickEqu.D
include SysEqu.D
include ToolEqu.D
includeMacTraps.D
MACRO .equ= equ| ; convert lisa to mds
MACRO _hideCurs = _HideCursor|
MACRO _showCurs = _ShowCursor|
CrsrRect equ $83C;SysEqu stuff
grafGlob equ $0
; parameter offsets from the stack pointer:
bitH .equ 4 ; horizontal pixel coordinate
bitV .equ bitH+2 ; vertical pixel coordinate
plast .equ bitV+2 ; address just past last parameter
psize .equ plast-bitH ; size of parameters, in bytes
; entrance: set up a stack frame, save some registers, hide
; cursor if needed.
flipPix:
clr.w D2 ; clear flag saying cursor was hidden
movem.w bitH(A7),D0/D1 ; load v. and h. coordinates
;together
; see if we'll need to hide the cursor while we draw
lea CrsrRect+top,A0 ; point to rectangle the cursor
;covers
cmp.w (A0)+,D0 ; compare v to rect.top
blt.s nohide ; if too small (above r.top), don't
;hide
cmp.w (A0)+,D1 ; compare h to rect.left
blt.s nohide ; if too small (left of r.left), don't hide
cmp.w (A0)+,D0 ; compare v to rect.bottom
bge.s nohide ; if too large (below r.bottom), don't
;hide
cmp.w (A0)+,D1 ; compare h to rect.right
bge.s nohide ; if too large (right of r.right, don't
;hide
_hideCurs ; must briefly hide the cursor to draw here
move.w #1,D2 ; flag that we did so
nohide: swap D2 ; hidden or not: slide flag up to top of D2
move.l grafGlob(A5),A0 ; point to quickdraw globals
move.l thePort(A0),A0 ; point to the current grafport
mulu portBits+rowBytes(A0),D0 ; v. times stride is byte
;offset of row
move.b D1,D2 ; copy h. coord (low 3 bits) for bit offset
lsr.w #3,D1 ; extract byte offset
add.w D1,D0 ; combine v. and byte component of h.
not.b D2 ; make the bit# 68000-style (x := 7-x)
move.l portBits+baseAddr(A0),A0 ; pick up base address
;of bitmap
bchg D2,0(A0,D0.w) ; flip the bit in the right byte
swap D2 ; bring back cursor-hidden flag
tst.w D2 ; is it set?
beq.s return ; no -- all done
_showCurs ; yes -- show the cursor
return:
move.l (A7)+,A0 ; pop return address
add.l #psize,A7 ; unstack parameters
jmp (A0) ; home to mother
end ; of procedure flipPix
; Smallflight_rscs.asm
; resource file for the Small Flight Program
; created using the assembler
; signiture is creator tag
;
RESOURCE 'SMFL' 0 'IDENTIFICATION'
DC.B 12, 'SMALL FLIGHT'
.ALIGN 2
RESOURCE 'BNDL' 128 'BUNDLE'
DC.L 'SMFL';NAME OF SIGNATURE
DC.W 0,1 ;DATA (DOESN'T CHANGE)
DC.L 'ICN#';ICON MAPPINGS
DC.W0 ;NUMBER OF MAPPINGS-1
DC.W 0,128 ;MAP 0 TO ICON 128
DC.L 'FREF';FREF MAPPINGS
DC.W0 ;NUMBER OF MAPPINGS-1
DC.W 0,128 ;MAP 0 TO FREF 128
RESOURCE 'FREF' 128 'FREF 1'
DC.B 'APPL', 0, 0, 0
.ALIGN 2
RESOURCE 'ICN#' 128 'MY ICON'
; FIRST APPLICATION ICON BIT MAP
INCLUDE ICON.TXT
Link file
!PAS$Xfer
]
)
/OUTPUT Small Flight Demo
/Globals -4
Small Flight
FlipPix
PAS$Sys
OSTraps
ToolTraps
/TYPE 'APPL' 'SMFL'
/BUNDLE
/RESOURCES
SMALLFLIGHT_RSCS
$