I have a situation where I want to interpolate a value from a HLSL vertex shader in screen space - not perspective-correct world space, as is done by default.

I'm rendering a 3D mesh in world space as you normally would, but I want to have some values that depend only on the screen space (post-projection) position passed to the pixel shader, and I want those values to be interpolated linearly in screen space, not world space.

Right now, the interpolation is using the w from the real vertex position to do world-space perspective correct interpolation, which is wrong for linear in screen space. It's correct at the vertices, but wrong for the interiors, which is not good enough for my situation in which I have very large tris.

I tried doing the W division myself in the vshader which makes every thing work like I want it to (since the output W becomes 1), except that then the hardware near plane clipping doesn't work right (triangles pop out as soon as they touch the plane).

I could do what I want by using the VPOS register in the pixel shader, but I'm trying to save some cycles by doing some computations in the vertex shader and passing the result to the pixel shader.

Any ideas on how I can change the nature of the interpolation?

I'm using HLSL and DX9.0c.

just a small guess: set the interpolator-coord w to the same, or the inverse, of the vertex-position w? so that you get a "perspective texture projection" wich wich undoes the perspective correction..

no clue if something like this could work, but if i wouldn't go to bed now, i'd think about this right now. :D

Not a bad idea, but unfortunately this would mean that I have to do the division myself in the pixel shader, which causes me to have to do some other operations too. What you seem to be saying is to pass the X, Y, and W values to the pixel shader and divide per pixel, but this is exactly the thing I'm trying to optimize.

If it was a real texture coordinate, I could use one of the "proj" functions and get the division for free, but I'm actually using these values for some other calculations and so I can't do that.

You can literally "project" your texture (see projective texture mapping). In your case the projector would have the same location and orientation as your camera (same matrix): this has the effect to undo the perspective correction.

Note that due to precision errors, you will encounter some glitches with this method (the fetched texel is not always exactly the one expected).

I guess there is a much simpler and robust method:
Use vertex color instead of texture coordinates. Normally they are always ineary interpolated (no perspective correction).

Projecting a texture, as in projective texture mapping, is the same thing as doing the division by W in the pixel shader, which, as I stated, I was trying to avoid. Consider how the projection would actually be implemented - either by explicitly dividing, or by a variant of tex2Dproj. But anyway, who said I am texture mapping :)? I am using these values for some other lighting calculations.

Also you are mistaken about the color interpolators being linear in screen space, instead of perspective interpolated. If they were not perspective correct, you would see them shifting and changing as you moved the camera, which obviously doesn't happen as demonstrated by any number of PC games. Also the direct X chm file states that "Color values input to the pixel shader are assumed to be perspective correct".