pouët.net

Go to bottom

star field by VLA

ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
;
;     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.
Go to top