I'm writing a software rasterizer. I've got it to the point right now where it can draw unlit, perspective-correct texture mapped, z buffered triangles. I'm doing this because I never have and I feel that if a programmer is going to use an API like OpenGL or DirectX, they should understand what is going on behind the scenes. Anyway, one of the references I'm using is a book from 1995 called "Cutting-Edge 3D Game Programming with C++" by John De Goes. It isn't the best reference to be sure, but he does write a perspective corrected texture mapper and it got me going. One thing he mentions is that z values cannot be interpolated across the polygon because they are not linear in screen space, but 1/z values are. He really doesn't give much of an explanation as to why this is, but since I don't know myself, I am dutifully following this advice. I really do not like not knowing why something is or is not happening in my code. Can someone clarify this for me?

Yes, that is what he's doing in the book.

Hmm... It would seem that 1/z isn't linear either. I checked some dummy non-linear z values by hand (1,2,7,12) and their reciprocals (1,.5,.142,.083) and interpolating the reciprocal provides the wrong values (1,.5415,.31225,.083).

I really don't know what he was talking about.

The reason it is not linear in screenspace is quite easy to see if you look at a 3D line and its corresponding 2D projection. If you partition the 3D line into n equally spaced points, the projections of those points are not equally spaced on the projected line. hence, moving linear on the 2D projected line corresponds to moving nonlinearly on the 3D line.

You can linearly interpolate 1/z in 2D space though, and there is a proof in one of Lamothe's books, and I Believe Eberly's first 3D engine book also proves it or at least gives you the general formula from which you can prove it.