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?