Forum archive

Roll effect (rotation) in Build

Return to forum index

• Apprentice at 2007-04-15 05:05
  Ken, how did you do the roll rotation in Build? With a trick or is it perspective correct?
• Awesoken at 2007-04-15 07:47

  Re: Roll effect (rotation) in Build

  The classic Build renderer does not handle roll natively. Here's how it is done:
  1. I allocate a 320*320 buffer in non-video memory. (I use a tile index to simplify some things in the code.)
  2. I render the regular view to this tile instead of the screen. (See setviewtotile()).
  3. Using rotatesprite(), I draw the tile to the screen at the specified angle.
• Apprentice at 2007-04-15 08:10
  And your rotatesprite() routine makes a rotation for each pixel or for each horiz/vert line (if so then this wouldn't produce gaps?) ?
• Awesoken at 2007-04-15 12:05
  Oh my. You are describing a very naive method of texture mapping called "forward" mapping. It suffers from gaps and overdraw, just as you describe. In forward mapping, you visit every texel of the source texture, transform it to destination (screen) coordinates, and plot a pixel there. The only advantage to forward mapping is the code is simple.
  
  A much better method is "reverse" mapping, where you visit each pixel of the destination (screen), and do an inverse transformation to find where in the texture (source) to read from. For reverse mapping to run fast, you only want to draw the parts that are covered by your polygon. You must "rasterize" the polygon, which means to chop it into a list of horizontal spans.
• Apprentice at 2007-04-15 17:24
  Sorry for the stupid question!
  Ok, I thought at a similar thing: to use the texture mapping equations to do reverse mapping because the Z coordonate (Y in your coordonate system) is constant. Something like this? :P
• Awesoken at 2007-04-16 00:44
  It sounds like you are reading texture mapping tutorials without really understanding them. Constant depth is an optimization for the inner loop of texture mapping, and it applies to forward and reverse mapping in exactly the same way.
  
  For those who are unaware: When you texture-map a straight line (either horizontal, vertical, or diagonal), and you know in advance that the two endpoints are at the same depth (I'm talking about distance in the direction that is perpendicular to the screen, not pythagorean distance), then you can use a faster inner loop that has no divides. In this case, the denominator of the transformation & projection calculations will be a constant, so you can get away with a single divide for the entire line. This situation occurs in Build classic, for drawing walls in the vertical direction, ceilings & floors in the horizontal direction, and 2D rotation ala rotatesprite in any direction.
• Apprentice at 2007-04-16 01:54
  I didn't read many perfect texture mapping tutorials because I know how to demonstrate those equations mathematically. The only problem is I don't rule very good over the 3D graphics "vocabulary" (I don't want to find me excuses but I'm a romanian and we do not have these things well documented, the only source being the web).
  I didn't reffer at my idea in the right way. I wanted to say that I could use some sort of texture mapping without projections since I work with buffers for a 2D rotation. In that case (I defined my projection formula to be something like this SX/SY=HalfScreenWidth/HalfScreenHeight+/-ScreenWidth/ScreenHeight*X/Y *1/Z, let's say SX/SY=X/Y *1/Z) Z is a constant and equals 1 so that SX/SY don't get changed.
  I reffered to three vectors for defining the rotated polygon: P {X,Y,Z}(corner position), M{X,Y,Z},N{X,Y,Z} (orthogonal vectors linked by P).
  Then I formed this system:
  { x=P.X+M.X*U+N.X*V
  { y=P.Y+M.Y*U+N.Y*V
  { z=1
  
  where x,y,z are the "3D" point (withing the polygon) reffered by U,V (texels) in buffer mode.
  
  the projection formula would be SX=X/Z and SY=Y/Z but because Z=1 then it would be SX=X, SY=Y so no projective transformation would be performed so the system wouldn't get changed.
  
  we put U and V terms in the left member and the system is:
  { M.X*U+N.X*V=x-P.X
  { M.Y*U+N.Y*V=y-P.Y
  
  We apply Crammer's rule:
  
  A= (M.X    N.X)        B=(x-P.X)
       (M.Y    N.Y)             (y-P.Y)
  
  delta=det(A)=M.X*N.Y-M.Y*NX
  deltaU=det (x-P.X    N.X)=(x-P.X)*N.Y-N.X*(y-P.Y)
                   (y-P.Y    N.Y)
  deltaV=det (M.X       x-P.X)=M.X*(y-P.Y)-M.Y*(x-P.X)
                   (M.Y      y-P.Y)
  so:
  U=deltaU/delta=(x*N.Y-P.X*N.Y-y*N.X+N.X*P.Y)/(M.X*N.Y-M.Y*N.X)
  V=deltaV/delta=(y*M.X-M.X*P.Y-x*M.Y+M.Y*P.X)/(M.X*N.Y-M.Y*N.X)
  
  notations:
  N.X*P.Y-P.X*N.Y===A
  M.Y*P.X-M.X*P.Y===B
  M.X*N.Y-M.Y*N.X===C
  
  so:
  U=(x*N.Y-y*N.X+A)/C
  V=(y*M.X-x*M.Y+B)/C
  
  A,B,C=ct;
  
  The inner loop can be optimised as well as the walls/sprites/floor/ceillings in your/my engine because we can run the screen coordonates horizontally or vertically (better horizontally because we have only 200 screen lines in 320/200/256 mode)->y=ct  so we can make only one division by horiz/vert line because that division can be precomputed. I know very well that's the way you optimised the texturing of the walls/floors/ceillings/sprites.
  
  This is my idea! I hope you understand better now what was I writing the last reply and that the notations are international.
  
  So I think that this would be reffered to reverse texture mapping and forward texture mapping would be the first system I described when you input U,V and get x,y mapped onto the rotated polygon.
  I also hope I didn't make any calculation errors because this was on the fly. I suppose your routine doesn't even by far look like this. What kind of operations involves your routine at pixel level?
  
  PS: I haven't tested this by now so I'm sorry if I wrote wrong data in here.
  
  Edited by Apprentice at 2007-04-16 05:08
• Awesoken at 2007-04-16 09:38
  You are free to look at my texture-mapping routines, which are located in A.ASM of the Build source code. You might be more interested in a C port of my assembler routines: look at A.C inside BUILDC.ZIP.
• Apprentice at 2007-04-16 13:46
  Thanks! Sorry, I know it isn't in the topic subject but what exactly are the mip-maps levels from the KVX file format? And why are 5 of them?
• Awesoken at 2007-04-17 01:02
  The mip-map levels are lower resolution versions of the full sprite (i.e. if the KVX model is 64x64x64, then the mip-map levels would be: 32x32x32, 16x16x16, 8x8x8, and 4x4x4). When a model is distant, the Build renderer switches to one of its lower resolution versions (scaled appropriately). Doing this saves a lot of CPU cycles.
• Apprentice at 2007-04-17 02:00
  Ok! sorry, two more question related to slabspri (I managed to compile it): why does it require a translucency table for the creation of the mip-map levels (for the paintings of the untouched by paint voxels?)? and what are the cross section and through modes?
  Edited by Apprentice at 2007-04-17 02:03
• Awesoken at 2007-04-17 13:31
  It seems like all your questions begin with 'sorry'. Anyway. KVX files use 8-bit color. I needed a way to mix colors and the transparency table offered a way to do that. It's certainly not the best method. A more accurate method would have been to average the color in 24-bit RGB space and then to find the closest palette entry to the resultant RGB. To view the 'cross section' and 'through' modes, you must first activate the 2D slice editor by using the enter key on the keypad.