3 ms·

I'll bite... what about the Sega Saturn's blitter?

jlokier 7y ago
Bearing in mind I didn't work on the Saturn. What I recall from others, for 3D rendering, the Sega Saturn: - Could only draw quadrilaterals with any corner coordinates, but not triangles. You need triangles to draw general 3D polygon shapes. Triangles could be simulated by setting two corners to the same position, but that doubled the amount of rendering due to the next points: - Drew quads in a strange way that overwrote lots of pixels repeatedly if they weren't screen-aligned rectangles. Instead of drawing horizontal spans on the screen to the bounds of the shape, as almost anyone else's renderer would do, so that each pixel was rendered once, it drew lots of sloping lines, starting with a line between points A and B at the "top" of the quad, working its way towards points C and D at the "bottom" of the quad, interpolating the endpoints and slopes appropriately. - Drawing the sloping lines would have been ok (though not as efficient for RAM access) if it had managed to still draw each pixel once by careful choice of line pixels. But instead, it just drew sloping lines on top of each other, with the effect that you got a combination of some pixels being drawn over more than once inside the quad (wasted time), and also gaps where no pixels were draw inside the quad (holes!). - To avoid the holes you had to ensure the line density was enough that you would definitely also have significant pixel duplication. The line density depended on the polygon's longest edge and its orientation after projecting from 3D to screen space. - When drawing a highly distorted quad that meant a lot of pixel duplication at the more "pinched" end. - Calculated texture coordinates by linear interpolation along these lines, instead of 3D projection. This made the texture look strongly distorted on quads not facing the viewer in 3D space, needing a workaround in software. - And then there was the difficulty figuring out how to get the hardware to actually do these things from the poor documentation and an enormous list of some 200 registers, without useful sample code or libraries. Drawing a good looking 3D textured polygon was tricky on this thing. Even when you had it drawing polys they looked wrong in all sorts of ways until compensated for, and still looked a bit wrong no matter what you did. And then you just knew it was much slower than it could have been given the rest of the hardware, bus speeds etc. It seems like the hardware designers had put a lot of effort into a complex chip, but unfortunately didn't understand much about 3D graphics.

Bearing in mind I didn't work on the Saturn. What I recall from others, for 3D rendering, the Sega Saturn: - Could only draw quadrilaterals with any corner coordinates, but not triangles. You need triangles to draw general 3D polygon shapes. Triangles could be simulated by setting two corners to the same position, but that doubled the amount of rendering due to the next points: - Drew quads in a strange way that overwrote lots of pixels repeatedly if they weren't screen-aligned rectangles. Instead of drawing horizontal spans on the screen to the bounds of the shape, as almost anyone else's renderer would do, so that each pixel was rendered once, it drew lots of sloping lines, starting with a line between points A and B at the "top" of the quad, working its way towards points C and D at the "bottom" of the quad, interpolating the endpoints and slopes appropriately. - Drawing the sloping lines would have been ok (though not as efficient for RAM access) if it had managed to still draw each pixel once by careful choice of line pixels. But instead, it just drew sloping lines on top of each other, with the effect that you got a combination of some pixels being drawn over more than once inside the quad (wasted time), and also gaps where no pixels were draw inside the quad (holes!). - To avoid the holes you had to ensure the line density was enough that you would definitely also have significant pixel duplication. The line density depended on the polygon's longest edge and its orientation after projecting from 3D to screen space. - When drawing a highly distorted quad that meant a lot of pixel duplication at the more "pinched" end. - Calculated texture coordinates by linear interpolation along these lines, instead of 3D projection. This made the texture look strongly distorted on quads not facing the viewer in 3D space, needing a workaround in software. - And then there was the difficulty figuring out how to get the hardware to actually do these things from the poor documentation and an enormous list of some 200 registers, without useful sample code or libraries. Drawing a good looking 3D textured polygon was tricky on this thing. Even when you had it drawing polys they looked wrong in all sorts of ways until compensated for, and still looked a bit wrong no matter what you did. And then you just knew it was much slower than it could have been given the rest of the hardware, bus speeds etc. It seems like the hardware designers had put a lot of effort into a complex chip, but unfortunately didn't understand much about 3D graphics.