ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
;
; TITLE: Star field
;WRITTEN BY: DRAEDEN
; DATE: 03/15/93
;
; NOTES:
;
;ASSOCIATED FILES:
;
; STARGEN.BAS => Basic program that generates a set of 'randomized'
; numbers. Creates STARRND.DW
;
; STARS.ASM => The asm file.
;
; STARRND.DW => File that contains a set of shuffled numbers order.
; Used to create 'random' star field.
;
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
A star field is just a series of 3d point plotted onto a 2d plane (your
screen). The movement effect is achieved by simply decreasing the Z
cordinate and redisplaying the results. The formula for the 3d to 2d
conversion is:
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
ScreenX = ScreenDist * Xpos / Zpos
ScreenY = ScreenDist * Ypos / Zpos
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
This should make perfect sense. As the object gets futher away, (X,Y)
cordinates converge to (0,0). The screen dist is how far away the 'eye' is
from the screen, or, as I like to think of it, the window. Naturally, as you
get closer to the window, your field of view is greatly enhanced (you can see
more). But, because we can't make the monitor bigger, we have to shrink the
data that is being displayed. And when we have a large screen distance, we
should see less of the virtual world, and the objects should appear bigger.
When this formula is translated into assembler, you would immediatly decide
that 256 is the best screen distance. Why? Multiplying by 256 on the 386 is
as simple as this:
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
;we want to multiply ax by 256 and put it into dx:ax to set up for division
movsx dx,ah ;3 cycles
shl ax,8 ;3 cycles -- total 6
;or we could do it the 'normal way'...
mov dx,256 ;2 cycles, but we can have any screen distance
imul dx ;9-22 cycles on a 386, 13-26 on a 486
;a total of 11-28 cycles!
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
If you'll take note, the 6 cycle trick is AT LEAST 5 cycles faster than
the imul. Anyway... I bet you really don't care about a few cycles at this
point, so I won't spend much more time on it...
So, as you can see, the math part of it is easy.. the hard part is the
what's left. You need a routine that creates a star, presumably random, and
another routine that displays all the stars and advances them. Well, that's
how I broke it into subroutines...
For the routine that creates the star you need it to:
1) See if we already have enough stars going (is NUMSTARS > MAXSTARS ?)
2) If there's room, scan for the first open slot...
3) Now that we've found where to put it, create a star by getting a set
of random numbers for the (X,Y) and setting the Z to the maximum.
Also select a color for the star.
The display routine would need to:
1) Erase the old star.
2) Calculate the screen X & Y positions for the new position. Are they
inside the screen boundries? If not, 'kill' the star, otherwise
display it. The shade of the color to use must be calculated by
using the Z cordinate. Color = BaseColor + Zpos / 256
3) Decrease the Zpos.
And the main routine would:
1) Call MakeStars
2) Wait for verticle retrace
3) Call DisplayStars
4) Check for keypress, if there is one, handle it, if its not one we're
looking for then exit program.
5) Loop to step 1
To impliment this, we need to create an array of records which has enough
room for MAXSTARS. The record would contain the (X,Y,Z) cordinates, the
OldDi and the base color for the star. To create a star, it first checks to
see if there is room. If there is, then we scan through the array
looking%wor an open slot. If we don't find an empty space, then we don't
create a star. We create the star by grabbing a pair of (X,Y) cordinates
from the list of 'random' numbers and set the Z to MAXZPOS. Then, increase
NUMSTARS and return.
In displaying the star, we would like to only have to calculate DI once.
So we save off a copy of DI in an array after we calculate it for the drawing
so that erasing the dot is really quick. Next we calculate the new DI for
the dot. This is done by using the formula mentioned above and this one:
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
DI = ScreenY * ScreenWidth + ScreenX
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
When doing the math, care must be taken to make sure that:
a) the Zpos is not zero and X*256/ZPOS is not greater than 32767.
will cause a DIVIDE BY ZERO or a DIVIDE OVERFLOW
b) SY and SX do not go outside the border of the screen.
If either of these conditions are broken, the star must be terminated and
calculations for that star must be aborted. Actually, Zpos = 0 is used to
signify a nonactive star. To terminate the star, you'd simply change its
zpos to 0 and decrease NUMSTARS.
To create the different shades, I used:
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Color = BaseColor + Zpos/256
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
I used 256 as the number to divide by because that enables me to do no
dividing at all- I just use AH, because AH = AX / 256 (AH is the upper 8 bits
of AX). This relation suggests that the MAXZPOS shoul be 16*256 for 16
shades. So, the MAXZPOS = 4096. The palette will have to be set up so that
the shades go from light to black (lower # is lighter). Simple enough. (I
hope.)
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
RANDOM NUMBERS
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Well, not truly random numbers, but random enough for a starfield.
The problem:
There is no way on a PC to create truly random numbers with
great speed.
Solution:
Don't use truly random numbers. Use a chart of non-repeating,
shuffled numbers that fall within your desired range. That way
the stars will be evenly spread out and the creation of a new star
is incredably fast. ( A few MOV instructions) All you have to is grab
the number and increase the NEXTRANDOM pointer. I chose to fill in
the array half with positive numbers, half with negative with a
minimum distance of 10 from 0. I did this so that no stars will
'hit' the screen and just vanish. That doesn't look too good.
Here's the BASIC file that made my numbers for me...
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
NumStars = 400
dim RndArray(NumStars)
randomize (timer)
'fill the array with numbers from -Numstars/2 to -10
'and from 10 to Numstars/2
i=10
for r = 0 to NumStars/2
RndArray(r)=i
i=i+1
next
i=-10
for r = NumStars/2 to NumStars
RndArray(r)=i
i=i-1
next
'randomly shuffle them..
print "Total numbers: ";NumStars
print "Shuffling - Please wait... "
for q = 1 to numstars/5
for r = 0 to NumStars
swnum1 = int(rnd*NumStars+.5)
swap RndArray(swnum1),RndArray(r)
next
next
'write the numbers neatly to a file
open "starrnd.dw" for output as 1
cc= 0 ' CC is my "Column Control"
print#1, "StarRnd dw ";:print#1, using"####";RndArray(0)
for r = 1 to NumStars
IF cc=0 THEN ' is this the first one on the line?
print#1, "dw ";:print#1, using"####" ;RndArray(r);
ELSE
print#1, ",";:print#1, using"####"; RndArray(r);
END IF
cc=cc+1:if cc= 10 then cc=0:print#1," " 'goto the next line
next
close #1
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
This brings up another point. Whenever you can write a program in a
higher level language to create data for you, do it. It sure beats typing
then in by hand. For instance, the palette was made using the REPT macro,
the actual data is created by the compiler at compile time. Doing it that
way happens to be a whole lot easier than typing in every byte.
Last minute note: I rigged the plus and minus keys up so that they
control the 'Warpspeed' can be from 0 - MaxWarp, which I set to 90 or
something like that.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Well, that's it for now. See INFO.VLA for information on contacting us.
I would like some suggestions on what to write code for. What would you
like to see done? What code would you like to get your hands on?
Send question, comments, suggestions to draeden@u.washington.edu or post
on Phantasm BBS.