It does more or less the same thing as all 3D rendering systems: it has a transformation matrix.
The typical way to think of a transformation matrix is you have a vector which holds your X,Y position of a pixel. You multiply that vector by a matrix to get a new vector, which is the new position after transformation. Depending on the contents in the matrix, this can do rotation, flipping, moving, zooming, stretching, etc, etc. Any arbitrary transformation.
Mode 7 actually does that in reverse. Instead of taking a pixel position and translating it to find it's on-screen position, it takes an on-screen position and translates it to find what pixel should be drawn there.
The formula for this is in Anomie's wonderful "regs.txt" SNES reference doc:
Code:
The matrix transformation formula is:
[ X ] [ A B ] [ SX + M7HOFS - CX ] [ CX ]
[ ] = [ ] * [ ] + [ ]
[ Y ] [ C D ] [ SY + M7VOFS - CY ] [ CY ]
Note: SX/SY are screen coordinates. X/Y are coordinates in the playing
field from which the pixel is taken. If $211a bit 7 is clear, the
result is then restricted to 0<=X<=1023 and 0<=Y<=1023. If $211a bits 6
and 7 are both set and X or Y is less than 0 or greater than 1023, use
the low 3 bits of each to choose the pixel from character 0.
The bit-accurate formula seems to be something along the lines of:
#define CLIP(a) (((a)&0x2000)?((a)|~0x3ff):((a)&0x3ff))
X[0,y] = ((A*CLIP(HOFS-CX))&~63)
+ ((B*y)&~63) + ((B*CLIP(VOFS-CY))&~63)
+ (CX<<8)
Y[0,y] = ((C*CLIP(HOFS-CX))&~63)
+ ((D*y)&~63) + ((D*CLIP(VOFS-CY))&~63)
+ (CY<<8)
X[x,y] = X[x-1,y] + A
Y[x,y] = Y[x-1,y] + C
(In all cases, X[] and Y[] are fixed point with 8 bits of fraction)
X, Y = The pixel from the 1024x1024 BG to draw
SX, SY = Screen position to draw it
everything else: values that are configurable by the game.
@lidnariq: The delta X/Y thing is pretty interesting. I had always just assumed it did all the math for each pixel in the scanline. Would the delta approach have rounding errors?