Did the Sega Saturn support homogeneous transformations for graphics or only affine transformations?

Question

Warning: My question contains some assumptions and mumbo jumbo. I attempt to learn how this stuff works and its correct terminology. And though I've implemented some of it (not all) from scratch over the years, I've done it my own way. As a result I'm sure I'm misusing some terms. Nevertheless I have partial technical knowledge of it whereas the web and YouTube if chock full of people attempting to discuss them with even less technical knowledge and misusing the terminology even worse than me. But here we should have some people expert enough to the field.

Affine transformations of bitmapped graphics can achieve scaling, shearing, and 2D rotation.

Homogeneous transformations of bitmapped graphics can additionally achieve 3D perspective mapping with foreshortening.

The Super Nintendo supported affine transformations for scaling and rotation in hardware, but also supported the famous "Mode 7", which could achieve perspective homogeneous transformations in the ground plane, X/Z, only (I believe) by cleverly adjusting the affine transformation a bitmap was undergoing on each scanline, the Y-axis.

The original PlayStation 1 only supported affine transformation which resulted in warped textures since affine transformations cannot do perspective foreshortening without clever tricks like that used by SNES Mode 7.

As far as I'm aware all the later consoles supported texture mapping with full homogeneous transformations and hence perspective-correct textures.

But for the Sega Saturn I can't seem to find good technical details. It could definitely do full affine transformations and apparently wasn't originally designed with full 3D texture mapping so many techniques were used to try to match the 3D capabilities of competing consoles of the day as best they could, to varying degrees of success.

So apart from any other limitations, could the Saturn do homogeneous transformations, only affine transformations, or could it achieve or approximate perspective correct texture mapping using some kinds of tricks similar to what the SNES did?

(I never owned any console but I did my own 3D graphics programming from scratch in the 8-bit days and affine texture transformations from scratch later on, but never managed homogeneous transformations from scratch.)

---

I want to include some diagrams to show the difference between an affine warp and a perspective projection. I haven't found good ones yet but while searching I realized that many images on the net labelled as "affine" are actually triangle based and show a warped square with the two triangular halves warped differently. This is what the PS1 does I believe since it was triangle based and this may cause people to believe this is what affine warping always looks like. The Saturn was quad based so will look different because although the texture won't be perspective-correct, it also won't be made of two mismatching triangular halves.

There's also the possibility of rendering a large area as a series of adjacent squares or rectangles, where the vertices of each will be correctly 3D projected but the textures within won't be. I have a hunch this may be what the Saturn did, which would result in less ugly warping that on the PS1, but more warping than on any of the later consoles.

Here's an image showing a 2D checkerboard, a PS-1 style projection made up of two mismatched affine-warped (non perspective) triangles, and a correctly perspective-mapped one:

This second image contrasts two affine-warped checkerboards. One made up of two mismatched triangles as the PS1 would do. The second rendered as a single affine-warped quad. Note that neither are perspective correct.

Here we have the 2D texture in the top left, the affine warped image made of two mismatched triangles in the top right, the affine warped image made of a single quad in the bottom left, and the perspective (homogeneous) projection in the bottom right:

Answer 1

An addition to the answer by Olivier. Going by the code of the yabause emulator (see this file) the distorted sprite algorithm is essentially a bi-linear interpolation on the four corner vertices. (It would render your bottom left baboon for such a trapezoid shaped target.)

The actual algorithm is complicated by the way in which it makes discrete pixel steps and tries to correct for missing pixels in the result. This algorithm will produce near-correct perspective texture mapping only for the most trivial cases (orthogonal 2D transformations).

Note that this scheme also differs form the PSX affine texture mapping: the Saturn will render a quad differently than the PSX would by splitting it into two triangles.

In short: the Saturn uses neither affine, nor perspective correct texture mapping, but uses bi-linear interpolation on quads. It may in some simple cases give the same result.

A more in-depth exposition about bi-linear interpolation for quad rendering here (not Saturn specific).

Answer 2

All right, I'll try to sum it up.

Disclaimer: I never coded anything on Saturn, only theory. But I did try to code a PPU for the 32X (dubbed SuperVDP), and also a sprite deformation engine à la Neo Geo, still on 32X.

First of all, the Saturn indeed has two VDP, but only one (VDP1) can manipulate sprites. I won't talk about the second one (VDP2) as I don't know enough about it. But have a look at antime's vault. This may help ;).

Regarding your definitions of affine transformations, you said:

Affine transformations of bitmapped graphics can achieve scaling, shearing, and 2D rotation.

Let's quote from the Sega Saturn VDP1 User's manual which says that the VDP1 can:

• scale
• and distort

sprites.
The first picture easily tells us that the Saturn can scale and shear sprites. The second one shows us that it also can rotate sprites.
Great !

Regarding the perspective mapping now, this is an other story.
Of course the VDP1 can distort sprites, moving each corner of the quad as needed. Here, you could say that the VDP1 can apply perspective mapping ... but not exactly. Because even if main shape is good, the very perspective will be wrong. If we look at the distorted sprite in the above picture, we definitely can tell that this deformation is 2D only. If we try to figure it in a 3D world, something feels weird. That's because this transformation is a bit too affine indeed, and it preserves ratio between rows and columns.

If we take a look at a typical Mode 7 distorted background as you suggest, we can clearly see that the lowest lines, the lines from which the viewer is nearer, are bigger than the upper lines, the one from which the viewer is th furthest. That is what projections are, and that is what the Saturn lacks.

Finally, to sum it up:

• the VDP1 cannot apply any transformation, as with a transformation matrix, or something like glTransform.
• nevertheless, the VDP1 can achieve affine transformation, even a transformation that will look a bit like a 3D projection.
• the VDP1 can not achieve a true projection.
• I don't know whether the VDP2 can achieve a true projection.
• the Saturn can apply any effects (affine, homogeneous matrix, projection... you name it), with software. SH2 or DSP, your choice.

Finally, regarding the mighty - and underrated - Saturn, I'll leave the end quote to Yu Suzuki:

I think that only 1 in 100 programmers are good enough to get this kind of speed out of the Saturn.

Answer 3

I want to include some diagrams to show the difference between an affine warp and a perspective projection.

I also don't know gl

So here is some additional information that will help you understand the answers.

Graphic pipelines consist of several steps, and have changed a bit over time.

Very roughly speaking, you have a vertex transformation step, which uses a matrix multiplication. You can implement an affine transformation on any number of dimensions by using an augmented matrix and by extending the point coordinates with an additional "virtual" coordinate that is always one (homogenous coordinates). An affine transformation matrix will have zeros in the last row except for the last entry. If the last row has non-zero entries, you have a projective transformation (and you have to normalize the vectors again).

The vertices define the corners of a polygon mesh (often triangulated). On the polygons itself, a second step applies texture mapping by interpolating pixels, applying shading calculations (Gouroud or others), and so on. This is what you call an "affine" transformation, but in normal 3D-pipeline speak at this stage all transformations have already happened, and you are just shading pixels.

So in your terminology, all modern graphics hardware is "affine", no modern graphics hardware is "homogenous", and you are not aware that the actual affine/homogenous transformations happen before.

In modern terminology, the affine/homogenous transformations happen during vertex transformation, and it doesn't apply these words to the pixel shading.

What the Sega Saturn hardware can do is that the VDP1 actually has some 2D-hardware acceleration that would correspond to a modern pixel shader. So you could implement a modern 3D pipeline on the Saturn by doing the first vertex transformation step in software (and then you can do whatever transformations you like), and by using the quad hardware transformation as the pixel shader.

Note that the VDP2 actually has a full transformation matrix and 3D parameters for backgrounds, so the answer to your question

could the Saturn do homogeneous transformations, only affine transformations,

(in your terminology) is "the VDP1 does affine pixel interpolating transformations, the VDP2 does homogenous pixel interpolating transformations on backgrounds only". But none of this matters for a modern 3D pipeline, which works differently, and applies the terminology differently.

The answer seems to contain assumptions and mumbo jumbo.

Instead of insulting people who know those things, I'd suggest to actually learn something about modern 3D pipelines, then maybe you could understand the answers, and they wouldn't look like mumbo jumbo to you.