The Unsorted BBS Collection/thegreatunsorted.tar/thegreatunsorted/programming/asm_programming/3DROTATE.ZIP/3DROTATE.TXT

Text File | 1993-02-25 | 13KB | 346 lines

─────────────────────────────────────────────────────────────────────────────
;
;     TITLE: 3d rotate text file
;WRITTEN BY: DRAEDEN
;      DATE: 02/22/93
;
;     NOTES: 3dRotate.asm requires a 386 or better
;
;ASSOCIATED FILES:
;
;       BWPRINT.ASM =>  Displays signed and unsigned bytes (8 bit),
;                    >  words (16 bit), or double words(32 bit)
;
;       SINCOS.DW   =>  Contains data for the sine and cosine operations
;                    >  for a 256 degree circle. Values are multiplied by
;                    >  256 for fast calculations.
;
;       3DROTATE.ASM=>  The asm file.
;
;       MAKE.BAT    =>  The file that'll put it all together into an .EXE
;
────────────────────────────────────────────────────────────────────────────

Rotating a point around (0,0,0):

    Recall that the formula for rotating in 2d is:

    Xt = X*COS(φ) - Y*SIN(φ)
    Yt = X*SIN(φ) + Y*COS(φ)

    Rotations in the third deminsion simply involve rotating on all 3 planes.

    To rotate a point (X,Y,Z) around the point (0,0,0) you would use this
    algorithim:

    1st, rotate on the X axis

    Yt = Y*COS(Xan) - Z*SIN(Xan)
    Zt = Y*SIN(Xan) + Z*COS(Xan)
    Y = Yt              --  Note that you must not alter the cordinates
    Z = Zt              --   until both transforms are preformed

    Next, rotate on the Y axis

    Xt  = X*COS(Yan) - Z*SIN(Yan)
    Zt  = X*SIN(Yan) + Z*COS(Yan)
    X   = Xt
    Z   = Zt

    And finally, the Z axis

    Xt  = X*COS(Zan) - Y*SIN(Zan)
    Yt  = X*SIN(Zan) + Y*COS(Zan)
    X   = Xt
    Y   = Yt

    And thats it.  For a look at a quick implimentation, see the ASM file.

────────────────────────────────────────────────────────────────────────────

The Palette

    The palette consists of 256 color, each of which is made up of three
    bytes- red, green, & blue.  It is very important to note that each
    of the three bytes have a range of 0-63, because the VGA palette uses
    only 6 bit for each of the 3 colors (18 bits = 2^18 = 262,144 colors)

    The total size for a complete palette is 768 bytes (256*3)

WRITING the palette to the vga card can be done in one of two ways.  The
    first is to use VIDEO BIOS call which would go like this:

── method #1 ──
    mov     ax,cs                   ;in this example, the palette data is
    mov     es,ax                   ; stored in the code segment

    mov     dx,offset Palette       ;ES:DX points to palette data
    mov     ax,1012h                ;WRITE palette
    mov     bx,0                    ;start at color 0
    mov     cx,256                  ;and write all 256 of 'em
    int     10h
───────────────

    The major disadvantage to this technique is that it is SLOW. VERY SLOW.
    But, it is easier to impliment.  While you should not use this
    in a rotating palette routine, it can be used to write the palette in
    one time situations, such as setting up a palette for displaying a
    picture.

    The second way involves directly accessing the VGA card.  This is done
    as follows:

── method #2 ──
    mov     ax,cs                   ;the palette is in the code segment...
    mov     ds,ax

    mov     al,0                    ;the first color to write is # 0
    mov     dx,03c8h                ;VGA PEL address write mode register
    out     dx,al
    inc     dx                      ;VGA PEL data register (03c9h)
    mov     si,offset PalTmp        ;point DS:SI to Palette
    mov     cx,256*3                ;the number of byte to write
    rep     outsb                   ;and go
───────────────

    Note that all palettes should be done right after a verticle retrace
    completes, so the 'snow' is avoided.  This is done like this:
───────────────
    mov     dx,3dah
VRT:
    in      al,dx
    test    al,8
    jnz     VRT         ;wait until Verticle Retrace starts
NoVRT:
    in      al,dx
    test    al,8
    jz      NoVRT       ;wait until Verticle Retrace Ends
───────────────

    The way I implimented the palette rotate in this program was not the
    best way.  What I did is rotated the palette in host memory (make a
    copy of it exactly like I want it on the video card), and then write
    it to the video card.  The middle step is not needed.  I could have
    changed the code so that it is faster by doing the following:

    This rotates 16 colors. it starts the write a color # [index]
    be sure to never let [index] out of the range 0-15
    [BaseColor] is the color that is the first of the sixteen to
    rotate.

      Example: If you wanted to rotate color # 100-115 youd set
        [BaseColor] = 100  and
        [Index]     = what ever the index is (0-15)

── methid #3 ──
    mov     bx,[index]
    mov     ax,bx                   ;this bit of code is just a fast
    add     bx,bx                   ;way to multiple by three
    add     bx,ax                   ;using a few adds take onlt 6 clocks
                                    ;as compared to the 9-22 clocks for
                                    ; IMUL BX,3
    mov     bp,16*3
    sub     bp,bx                   ;bx holds length of first half
                                    ;bp holds length of second half
    mov     dx,03c8h
    mov     al,[BaseColor]          ;the color # to start write at
    mov     al,[index]              ;start on teh second half first
    out     dx,al
    inc     dx
    mov     si,offset PalTmp        ;the place where the palette data is
    mov     cx,bp
    rep     outsb                   ;and go

    or      bx,bx
    je      SkipSecondHalf

    dec     dx
    mov     al,[BaseColor]          ;start at relative color # 0
    out     dx,al
    inc     dx                      ;si is already where we want it
    mov     cx,bx                   ;load in the length
    rep     outsb                   ;and go
SkipSecondHalf:
    ...                             ;code continues
───────────────

    Although this works great for cycling the palette, it is not effective
    for fading out the palette.  To do this, you'd copy the current palette
    to a backup 768 byte buffer and then decrease every one of those 768
    bytes (but only if they are nonzero) and then write the entire backup
    palette using method #2.  This is very easy to impliment.

    But, if you were cycling the palette while fading, you'd want to
    do a hybrid of method #2 & #3. First you'd fade the palette, then you'd
    write all non-cycled areas and then write the rest of the palette using
    method #3.  If you get creative, you can make palette rotates very cool
    looking, and in fact its possible to do things that would be impossible
    without palette rotations.  Just take a look at our next demo whenever
    we get it done...

────────────────
And now the next part which I call - "The Nifty little cube that rotates
around and leaves a trail of fading out dots"

    Nice title, eh?
    If you haven't guessed yet, the fading trick was done with (get ready)
    a cycling palette.

    Here's how I put it together:

        First, I made the routine that rotates the dots.  I took the previous
      file, ROTATE.ASM and added in the 3rd (and 4th) fields in the point
      structure.  Then I had to fiddle a little with the rotate subroutine
      to make it rotate on all three axis.  This was a little tricky. Compare
      the code of ROTATE.ASM and 3DROTATE.ASM to see what I did.  Next, I
      had to come up with a little distance transform, so that the object
      could zoom out into the distace, or get really close.  Here's how
      to do that:

────────────────
    ScreenX = ScreenDist*Xpos/Zpos
    ScreenY = ScreenDist*Ypos/Zpos
────────────────

      For convience, I chose the ScreenDist to be 256 (anyone know why?)
      I also put some additions into the calculation for easy transforms.
      The newer version of the above formula is:

────────────────
    ScreenX = 256*(Xpos+PreXadd)/(Zpos+PreZadd) + PostXadd
    ScreenY = 256*(Ypos+PreYadd)/(Zpos+PreZadd) + PostYadd
────────────────

      For normal display, all the Pre adds would be zero and
          PostXadd = ScreenWidth/2
          PostYadd = ScreenHeight/2
      The post adds are for centering the object on the screen, and the
      preadds are for changing the 3d cordinates of the object.

      Finally, I implimented the formula.  Unfortunately, I could not
      avoid 2 divides. ( IDIV takes about 27 clocks )

────────────────
    mov     cx,[RotCord.Z +si]
    add     cx,[PreAddZ]        ;cx = Zpos + PreZadd

    mov     ax,[RotCord.Y +si]
    add     ax,[PreAddY]        ;ax = Ypos + PreYadd

    movsx   dx,ah           ;these two instructions effectivly do a
    shl     ax,8            ;signed multiply by 256, using 6 clocks instead
                            ;of the 9-22 that IMUL takes

    idiv    cx              ;you are witnessing the evils of depth emulation-
    add     ax,[PostAddY]   ; the divide that you just can't get rid of
    mov     di,ax
    cmp     di,200          ;see if we are out of the screen bounds, if
                            ;we are, quit calculating for this point now.
    jae     DontDraw
    imul    di,320          ;this IMUL should be replace by a look-up table,
                            ; since we do the same thing over and over..
                            ; you'd do it like this:
                            ;
                            ; add di,di
                            ; mov di,cs:[Imul320+di]
                            ;
                            ; where Imul320 has 200 entries for the index*320
                            ; Easy enough, and it takes only 6 cycles
    mov     ax,[RotCord.X +si]
    add     ax,[PreAddX]

    movsx   dx,ah           ;again the multiply
    shl     ax,8

    idiv    cx              ;Aaarrrgghh! Another one!
    add     ax,[PostAddX]

    cmp     ax,320          ;check range of xpos
    jae     DontDraw
    add     di,ax           ;di now points to where the dot should be drawn
────────────────

        Then, I noticed that I was keeping a list of previous 'OldDI' points
      so that I could erase the old dots quickly.  I thought, "hmmm..
      what would happen if I were to create multiple OldDi charts?"
        What would happen is that a trail would be left behind..  But that
      would be kinda lame, wouldn't it?  So I decided to put a rotating
      palette in there, too.  I'd set it up so that the bytes I just drew
      would be the brightest ones and all the others would "fade" out.
        It's a little difficult to explain, so just go look at the code, OK?

────────────────────────────────────────────────────────────────────────────

And now an explaination of SINCOS.DW

    SinCos.dw is a file which contians the sine of the 'angles' 0-255.  I
used 256 angles because it is very convienent, and there just happens to
be a data structure that has a range of 0-255.  It's called a BYTE, denoted
by 'DB'.
    The bit of code (in BASIC) that would generate this sort of chart is:

────────

    FOR i = 0 TO 255
        an = i*2*pi/256
        BYTE = INT( SIN( an )*256 +.5)
        >> Store BYTE in a file <<
    NEXT i

────────

    Modifying the basic rotation formula for our data file would yield:

    Xt = (X*COS(φ) - Y*SIN(φ)) / 256
    Yt = (X*SIN(φ) + Y*COS(φ)) / 256

    If you know your hexadecimal, you'd realise that dividing by 256 is
simply a "SAR XXX,8", where XXX is what you're dividing by 256.

    I expanded this into assembler, that not only works, but is very fast.
To see it, examine the RotateXY procedure.

────────────────────────────────────────────────────────────────────────────

BWPRINT.ASM contains three functions: PrintByte, PrintWord, and PrintBig.

    They do this:

    PrintByte: decodes a byte (in AL) and displays it as 3 digits plus a
            an optional sign.  If the carry is clear, it prints it as an
            unsigned integer.  If the carry is set, it prints it signed.

    ────
        EXAMPLE:
            mov     al,-50
            stc
            call    PrintByte
    ────

    PrintWord: decodes and prints a WORD (in AX) in 5 digits.

    ────
        EXAMPLE:
            mov     ax,50000
            clc
            call    PrintWord
    ────

    PrintBig:  decodes and prints a DOUBLEWORD (in EAX) in 10 digits.
                NOTE: PrintBig requires a 386 to use.
    ────
        EXAMPLE:
            mov     eax,-1234567890
            stc
            call    PrintBig
────────────────────────────────────────────────────────────────────────────

   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?

   Keep it easy, though.  I don't want to have to spend hours writing a DOC
   for it.  Just in case you're curious, I spent nearly as long on this doc
   as I did on the asm file...