Super Mario 64 for the PS1

> Tessellation (up to 2x) to reduce issues with large polygons

From the videos I've watched there is still insane amounts of affine transformation texture warping, is that because it's not enable or because 2x is not enough?

I guess they will need to also redo all level geometry to be more amenable to tesselation... I guess that's why many ps1 games had blocky looking levels.

It notes in the Known Issues section that "Tessellation is not good enough to fix all large polygons".

Maybe it just needs more tessellation or something else is going on, because you're right - even as someone who grew up on the PS1 and is accustomed to early 3D jank, it looks painfully janky.

I see a lot of texture warp like you mentioned but I'm not seeing the geometry popping (wobble?) that was a hallmark of ps1 games, I'm guessing they're using soft floating point for the geometry and doing perspective-correct texture mapping would just be too expensive for decent frame rate

The README mentions that it uses both (new) fixed point as well as soft floating point.

Unless I'm mistaken, the PS1 just plain doesn't support perspective correction. All texture mapping is done in hardware using a very not-programmable GPU; there'd be no way to do perspective correction, decent frame rate or not, outside of software rendering the whole thing (which would be beyond intractable).

The common workaround for this was, as suggested, tessellation - smaller polygons are going to suffer less from affine textures. Of course that does up your poly count.

right now there is basically no preprocessing of level polygons and they are copied as is, but when it is implemented, the largest polygons will be split to solve this

this is also necessary to fix the occasional stretched textures, as texture coordinates are also limited to a smaller range per polygon on PS1

The PS1's GPU does not support perspective correction at all; it doesn't even receive homogeneous 3D vertex coordinates, instead operating entirely in 2D screen space and leaving both 3D transformations and Z-sorting to the CPU [1]. While it is possible to perform perspective correct rendering in software, doing so in practice is extremely slow and the few games that pull it off are only able to do so by optimizing for a special case (see for instance the PS1 version of Doom rendering perspective correct walls by abusing polygons as "textured lines" [2]).

[1]: https://github.com/spicyjpeg/ps1-bare-metal/blob/main/src/08... - bit of a shameless plug, but notice how the Z coordinates are never sent to the GPU in this example.

[2]: https://fabiensanglard.net/doom_psx/index.html

it's not possible to have either subpixel vertex precision or perspective correct mapping with the PS1 GPU, as it only takes 2D whole-pixel coordinates for triangle vertices. (contrary to popular belief, N64 also uses exclusively fixed point for graphics btw, it just has subpixel units.) better tessellation can mitigate the perspective issues by a lot, but the vertex snapping is unsolvable, and it is indeed present here. look closer and you might see it.

Darn I posted the same thing in another thread

It's funny that the PS1 got so famous for 3d games, when its 'GPU' was entirely 2d.

I guess the main thing the console brought to the table that made 3d (more) feasible was that the CPU had a multiplication instruction?

Interesting!

I guess you could pretend to have sub-pixel precision on the PS1, if you did it manually? Eg change the colours around 'between pixels' or something like that?

But that would probably get very expensive very soon.

A little more than just a multiplication instruction (the 68000, used in, say, the Sega Mega Drive, had one of those too). Have a look at https://www.copetti.org/writings/consoles/playstation/, and in particular, read about the GTE - it offered quite a bit of hardware support for 3D math.

Also, even though it didn't handle truly 3D transformations, the rasterizer was built for pumping out texture mapped, Gouraud shaded triangles at an impressive clip for the time. That's not nothing for 3D, compared to an unaccelerated frame buffer or the sprite/tile approach of consoles past.

It's not just a multiplication instruction. The CPU is equipped with a fixed-point coprocessor to accelerate the most common computations in 3D games, the geometry transformation engine [1], capable of carrying them out much faster than the CPU alone could. For instance, the GTE can apply a transformation matrix to three vertices and project them in 23 cycles, while the CPU's own multiplier takes up to 13 cycles for a single multiplication and 36 (!) for a division. Combined with a few other "tricks" such as a DMA unit capable of parsing linked lists (which lets the CPU bucket sort polygons on the fly rather than having to emit them back-to-front in the first place), it allowed games to push a decent number of polygons (typically around 1-3k per frame) despite the somewhat subpar performance of the cache-less MIPS R3000 derivative Sony chose.

If you have some basic familiarity with C, you can see both the GTE and the Z bucket sorting of GPU commands in action in the cube example I linked in the parent comment.

[1]: https://psx-spx.consoledev.net/geometrytransformationengineg...