Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.
Sign up to join this community
A memorable part of the PlayStation 1 experience was “wobbly” 3D graphics, where (supposedly) straight edges would warp, jitter and pulse as the camera panned across a scene. This was especially apparent in 3D-heavy games like Metal Gear Solid, Vagrant Story and Time Crisis.
Why did this happen, and why was the defect completely absent on other platforms of the era (e.g. PC, Nintendo 64)?
The transform applied to project geometry from 3d to the 2d coordinates necessary for drawing on a screen is called a perspective projection. It involves calculating 1/z and multiplying x and y by that.
Filling a triangle involves visiting every pixel within it and deciding which colour to put there. To paint a texture that properly obeys perspective you'd need to perform a divide stemming from that 1/z operation for every pixel.
Divides are expensive so the original Playstation doesn't do them. It just squeezes the texture to fit, disregarding any consideration of perspective. That's only mathematically correct if 1/z is constant over the entire triangle, so you tend to see greater problems with geometry as it gets to a greater angle and as it gets closer to the camera.
Genuine perspective:
Ignoring z (i.e. affine):
Given this constraint, a second issue arises: the standard on the Playstation is to use small triangles because then 1/z can't vary too much across the face. Or, spun another way, texture coordinates are correct anywhere there's an actual vertex, just a bit variable in between, so a higher number of vertices is desirable. A good game will even subdivide larger triangles as they get closer to the camera.
But then clipping the geometry — discarding those parts that fall behind the camera from triangles that are partly in front and partly behind — becomes an expense to do away with. A lot of titles just delete any triangle completely behind the camera, keep any wholly in front, and from the others subdivide to a point but then just push the vertices that should be behind to just in front. Mathematically they should be calculating brand new geometry that is exactly cut by the camera. That adds a sort of liquid effect, where camera motion slightly deforms near geometry by compressing it and moving it around.
So: the very near geometry can be slightly adjusted, and the pixel contents of each triangle are inexact.
There's also a lack of subpixel precision that further reduces precision at triangle edges and more subtly within their fills. The issue there is that the vertices the describe the boundary of a triangle are stored as integers, precise only to the nearest whole pixel. That's enough information to locate them exactly but it affects how precisely you can calculate the on-screen positions of all other edge pixels, and how well you can map back from the screen to the source texture when filling in the middle.
For example, imagine a triangle edge that begins in the pixel at (x, 0) and ends in the pixel at (x+1, 100). You know definitely which column the starting pixel must be in. You know definitely which column the ending pixel should be in. But exactly where should you switch column? Whatever choice you make, it's going to be exactly the same for every frame where the start and end vertices fall at those two locations. But what if the camera is panning very slowly, and, say, every sixth frame the edge moves one pixel to the left? Without subpixel accuracy, the entire edge will appear to be static for six frames and then suddenly leap. Supposing everything else on screen isn't moving at exactly the same rate, it'll appear not to move entirely with the scene. There's an overall shakiness, as the various different vertices all jump from one pixel to the next at different times, making it look like some frames are updating some part of the display, other frames are updating others even though every single pixel was drawn for every single frame.
If instead you knew that you were drawing from, say, (x + 0.1, 0) to (x + 1.3, 100) in one frame, then from (x + 0.3, 0) to (x + 1.4, 100) in the next, you'd actually factor that into exactly how the edge runs, and exactly how you apply the texture. The user gets enough feedback that the polygon now looks like it is moving entirely with the scene, as there's then a consistent precision applied to the entire pipeline of all rendered pixels, rather than there being a step where an amount of precision is thrown away that is a function of current vertex position.
A secondary problem is that the process of actually assigning pixels to polygons has a bit of a quirk to it. Taking OpenGL as an example because it's well documented, the main rule is that a pixel is considered part of a triangle if its centre falls within the triangle. But that leaves a literal edge case: what do you do with a pixel whose centre lies exactly on the edge of a triangle? If you always draw it then triangles that meet along that edge are both going to draw the pixel and that'll both cost more and ruin any transparency you're applying. If you never draw it then it won't be painted at all and triangles that should meet will show occasional gaps.
There's an easy fix for this, which is to paint pixels exactly on the boundary only if, in terms of the 2d screen, they're on e.g. the left or the top edge of the triangle. But there's a potential precision problem there because you're now testing for an exact match, and hoping to get the same result on at least two separate occasions. So some hardware and some software will sometimes still show individual pixel gaps between geometry that should meet up.
The problem is exacerbated on the Playstation because you might have started with two triangles sharing one edge but then subdivided only one of those polygons. So what was one edge on one side has turned into two edges. And the lack of subpixel precision means that the new vertex in the middle might not exactly be where it should once you've projected it.
Dealing with that is a per-developer problem, but tends to revolve around deliberate more aggressive stripping of precision or stretching geometry to be slightly larger than it would naturally be. In both cases you increase that shaky look (either because precision is worse, or because you did something else directly in projected pixels), and you often also get a greater sense of polygons fighting each other for boundary pixels frame-to-frame.
Finally, the Playstation uses a fixed point 16.16 representation for numbers. That doesn't allow as much localisation of precision as floating point, and means that a developer needs actually to think relatively carefully about game distance units. It's usually not a problem for the sort of draw distances that are realistic on that generation of hardware but a particular developer could deal with that poorly. Shouldn't be an issue for the Metal Gear Solids, Vagrant Stories or Time Crises of the world though.
