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.
Brush model Z-Fighting Fix
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...
Of course we've all seen timedemos that give anomalous results from time to time too...
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
-
- Posts: 268
- Joined: Tue Nov 24, 2009 2:20 am
- Contact:
This. ++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.
Get off my lawn!Ken Thompson wrote:One of my most productive days was throwing away 1000 lines of code.