This idea is very applicable and it has already been applied, it's a depth buffer. Most, if not all, video cards released in the past year or so supports a depth buffer in hardware.

Actually, what he's describing here is not a depth buffer, most obviously because it stores no depth information. Sounds like a good idea though. I'd suggest testing it out and seeing what kind of performance gains it gives you.

Thanks for your responses. As for coding it out to see how it would work, I don't have the experience(Still doing that damn wire-frame cube). Also, I had another thought. Instead of testing the o-buffer when filling a polygon, perhaps it would be better to loop through the o-buffer and compare every polygon that would project onto that pixel, and then draw the closests. The drawback is that it would have to loop 640*420 times or so depending on your resolution, but it seems much more rigid than my original idea. If anyone is willing to try this, let me know how it works out.

I was thinking on this recently and was wondering if the idea is applicable. Basically, you set up a buffer(I'll call it o-buffer, for overdraw) with the same dimensions as your screen. After sorting your polygons, draw the CLOSEST ones first, and mark off the pixels drawn in your o-buffer. Then, when drawing polygons behind the closer ones, you just check your o-buffer to see if that pixel has already been drawn. If it has, you move on, if not, texture map away. Any ideas or thoughts? THANKS! PS-I know there are better ways.

There are some drawbacks:

The approach assumes there IS a front to back order (I.e. no cyclic overlaps).

There is no way it can be faster than HW Z-buffer (which, when drawing front to back, does the same job)...

Only difference between Z-buffer and your O-buffer as far as I can tell is a potential save in memory usage (1 byte vs. 2 or 4 per pixel - assuming a bitfield is excluded for performance reasons). And with HW Z-buffer this is REALLY a minor issue.

/Niels