←back to thread

Super Mario 64 for the PS1

(github.com)
300 points LaserDiscMan | 5 comments | 10 Dec 25 18:58 UTC | HN request time: 0.001s | source
Show context
amlib ◴[10 Dec 25 19:57 UTC] No.46222841[source]▶
> 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.

replies(3): >>46223805 #>>46223821 #>>46224091 #
mewse-hn ◴[10 Dec 25 21:04 UTC] No.46223821[source]▶
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
replies(3): >>46224016 #>>46224199 #>>46224242 #
1. spicyjpeg ◴[10 Dec 25 21:34 UTC] No.46224199[source]▶
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

replies(2): >>46224561 #>>46228410 #
2. LarsDu88 ◴[10 Dec 25 22:06 UTC] No.46224561[source]▶
Darn I posted the same thing in another thread
3. eru ◴[11 Dec 25 06:51 UTC] No.46228410[source]▶
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?

replies(2): >>46229047 #>>46229166 #
4. wk_end ◴[11 Dec 25 08:44 UTC] No.46229047[source]▶
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.

5. spicyjpeg ◴[11 Dec 25 09:04 UTC] No.46229166[source]▶
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...