InsideQC Forums

The only way this could concievably provide any speed up would be if it allowed slightly more polygons to be rejected by early depth testing, which is entirely possible (due to the polygons which would otherwise be visible but z-fighting now being hidden fully).

I wouldn't doubt that a speedup did come on account of that, and even that in some cases it might be noticeable, but it's important to understand why it went faster and that the reason why is nothing to do with a z-fighting "fix" but more to do with normal operation of your z-buffer.

Anyway, I've largely given up on the whole idea of a z-fighting "fix" at this point in time. It's a content bug, pure and simple, and should be the responsibility of the mapper. Nothing you can do in engine code can completely eliminate it perfectly, and any half-way solution can only cause other artefacts and visual discontinuities, which - in many cases - may be even more objectionable.

And don't even mention polygon offset - polygon offset sucks.

I seriously doubt that's the case considering PSP Quake is very CPU-bound in the first place, and I'm not even sure if the PSP supports early depth testing the same way OpenGL does.

I'm not going to question that as I don't know PSP hardware enough to say anything. I'm just describing the one scenario in which this could potentially run faster.

Of course we've all seen timedemos that give anomalous results from time to time too...

mh wrote: Anyway, I've largely given up on the whole idea of a z-fighting "fix" at this point in time. It's a content bug, pure and simple, and should be the responsibility of the mapper.

This. ++