Jump to content

Affine perspective rendering question


Recommended Posts

So, please correct me if I'm wrong here, but it would appear that PC Doom does not calculate along the Y axis for perspective, causing geometry to be vertically parallel rather than shearing toward a central point, as in three-point perspective. Doom is effectively rendered in two-point perspective, which saves on compute time. The Jaguar version, from which several other ports (Genesis 32x, 3DO, Saturn, PS1) were derived, treat individual texels on walls/foors as either quads or tris, in order to maintain correct perspective, and avoid the swimmy zig-zags of affine texture mapping. What would have prevented these different hardware platforms from rendering textured triangles/quads with affine perspective on the Y-axis, like the original? If this had been possible, could it have been combined with subdividing the map into smaller units like a lot of PS1 games were? Could affine texture mapping be turned off or was that a hardwired thing from the 32-bit era?

Edited by Koko Ricky

Share this post


Link to post

I think that you are thinking of the PS1 version exclusively. The Jaguar version and most versions derived from it are completely software rendered like the PC version. The 32x doesn't even have any 3D hardware, that system's graphical capabilities are pretty much just the Mega Drive's VDP with a framebuffer overlaid on the image output.

Edited by Individualised

Share this post


Link to post

Most consoles of the era did not really have any sort of perspective correction. PS1, in particular, had none, so even though it could've been "hardware" rendered, it would've still had the affine texture swim. Basically, texture perspective correction would've always been something you'd have to do in software since the graphics hardware of the time could not do this, and the systems of the time simply did not have the grunt to do that. (Notable exception: The N64 was fully capable of perspective correction in hardware.)

 

As you said, a lot of games of the era got around texture swim by subdividing larger surfaces into smaller triangles, since the warping would've then been on a per-triangle basis, considerably reducing the effect (but it was still completely possible to occur). PS1 Doom predated these approaches, probably because it was such an early game for the console, but it came up with a more-or-less similar idea: Subdividing the rendered view into pixel-wide polygonal strips. The warping would thus be pretty much eliminated, but the cost of this was that it pushed an insane number of polygons per frame, and that's a large reason of why the framerate can occasionally be brutal on maps where there's a lot of distant drawing and so on.

 

In theory though, sure, the renderer could be rewritten in order to do it more like later PS1 games did. Whether or not somebody wants to do that is a whole other question entirely.

Edited by Dark Pulse

Share this post


Link to post

Thank you for the explanation! So as for the Jaguar, Saturn, 32x, and 3DO versions, are those all software rendered like PC?

Share this post


Link to post

Yes and no. Jaguar and 32X use 100% software rendering, just like the vanilla. Saturn uses hardware-accelerated rendering of columns and spans. The 3DO version also uses a native form of hardware acceleration to render columns and spans, which in Doom's case is actually more like hardware deceleration.

Edited by Vic

Share this post


Link to post
12 hours ago, Vic said:

Yes and no. Jaguar and 32X use 100% software rendering, just like the vanilla. Saturn uses hardware-accelerated rendering of columns and spans. The 3DO version also uses a native form of hardware acceleration to render columns and spans, which in Doom's case is actually more like hardware deceleration.

IIRC, 3DO is only partial. Columns and spans are accelerated, but all the ceilings and floors are still done entirely in software (and are a large chunk of why the performance is so abysmal, since the 3DO's CPU was pretty weak for it).

 

We're talking an ARM60 (ARMv3) running at a mere 12.5 MHz. No cache, no MMU (though it did have a custom math coprocessor). Not even 1 MIPS/MHz (a 12 MHz chip got about 10 MIPS). Fucking yikes.

Edited by Dark Pulse

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...