/vr/ - Retro Games

>>3143798
>>3143797
For a less copypasted explanation, z-fighting is the glitchy black/flickery shit you see when two walls sit in the exact same spot and as you move yourself/the camera around that one spot spazzes out like it can't decide which wall to draw (which is exactly what's happening).

>>3143804
Yeah, I know (Quakespasm still lists Fitzquake 0.85 in the console when you start a map), I was just interested in what little things exactly were changed.

>>2290659
>Pretty sure the end result of all graphical errors are once per frame, since that's the only time you can see them
z-fighting, compared to missorted polygons, tends to be very visible.

>great chunk of polygons
z-fighting happens between two closely aligned polygons.

>literally breaking perspective
The affected polygons are correctly transformed, the only issue is draw order.

>a few intersecting pixels
If only z-fighting was that unnoticable

>but the effect that occurs without a z-buffer
It can't, as z-fighting is a per-pixel artifact.

>you have a LOT of pixels improperly intersecting
Without any flickering or oddities.

>subdividing will fix everything, not.
Everything a z-buffer can fix in terms of polygon intersections, yes. Of course there's a draw back. Determining the splits is complex, and higher polygon count is not helpful for these dated engines.

>glitchy shit
Are you telling people that elite, stunts, indy, wolfenstein 3d, magic carpet, quake, descent, syndicate wars or nfs 2 are glitchy messes?

>Somebody who doesn't want to waste computation?
Enough that in order to not "waste" it, they need to sacrifice large amounts of very limited vram, and saturated the already stressed memory throughput? Didn't think so

>Because the RAM wasn't fast enough.
Among many other things. Also, because the gain was too minimal for the drawback

>Projection
At least it's perspective-correct.