3d Rotate Text File   by Independent (IND)

───────────────────────────────────────────────────────────────────────────── ; ; 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...