D_DrawPoly

[leileilol]

Anyone ever tried implementing that function (in the software renderer) and enabling it out of curiosity? The code for drawing it was clearly removed from the source release, but the rest of it (setting the world to draw for it) is still there. Maybe it's also related to polysets. Maybe Romero has an early remnant of it, could be dating back to early 1995 before the first Quake TIF screenshots.

[mankrip]

MDL models features polygons that always have 3 edges (i.e. triangles), but the polygons in BSP models (i.e. faces) can have many more. As I understand, D_DrawPoly was made to draw BSP faces on the screen, similarly to how MDL triangles are rendered but most likely featuring perspective correction.

IIRC, the code to get D_DrawPoly to run seems to be incomplete. I've tried to enable it a few times without success.
Anyway, the difference would certainly be that it used absolutely no optimization to prevent overdraw. I'm sure D_DrawPoly used Z buffer checks for each pixel instead, just like the MDL triangle renderer does. This also means that the BSP renderer didn't render the Z buffer values of BSP faces's pixels in a separated step at the time.

I suspect that translucent BSP faces in the software renderer of Quake 2 are rendered in a similar way.

And I was also aiming to figure out how to bypass the whole optimized rendering code for BSP faces, so specific BSP faces could be rendered individually as fast as possible. That would allow for "fence textures", and would probably help to make translucent water a bit faster in some areas. I'd still use the optimized BSP code on translucent BSP entities though, because I don't like when translucent entities overdraw themselves.

[Spike]

I always thought it was something to do with vquake.
the fact that R_ZDrawSubmodelPolys just calls R_RenderPoly shows that D_DrawPoly does indeed need to draw its own depth values. Yes, this would mean that there is overdraw, but if you have actual hardware (with decent zbuffer support) to draw the poly then its probably still going to be faster than trying to figure out all the spans and clipping them, etc.
I assume that you would need to replace more than just D_DrawPoly for it to be complete, at a minimum d_init.c too. it likely expects all the d_*.c files to be replaced.

[qbism]

Q2 software renderer has R_DrawPoly called by R_ClipAndDrawPoly, used by alpha surfaces and sprites.

[leileilol]

I think that was used for lasers. Translucent surfaces used some derivative of the Turbulent8 code without the turb IIRC, causing some really malformed looking glass.