The key points of this approach are that eye linear tcGen is a function of vertex eye coordinates, which is a result of both eye properties and object space vertex coordinates (more specifically, the object space vertex position is transformed by the model-view-projection matrix). Because of that, the corresponding texture matrix can be used to "shift" the eye properties so the concatenated result is the same as using an eye linear tcGen from a point of view which can be different from the observer.
The previous algorithm can then be reformulated by simply considering two model-view-projection matrices: one from the eye point of view and the other from the projector point of view.
In this case, the projector model-view-projection matrix is essentially the aforementioned concatenation of eye-linear tcGen with the intended projector shift function. By using those two matrices, a few instructions are sufficient to output the transformed eye space vertex position and a projective texture coordinate. This coordinate is simply obtained by considering the projector's model-view-projection matrix: in other words, this is the eye-space vertex position if the considered projector would have been an observer.
Defining properties of those spaces is beyond the scope of this article but it's well known that textures should usually be addressed in the range [0..1] while eye space coordinates are addressed in the range [-1..1]. According to the used texture wrap mode various artifacts may occur but it's obvious a shift and scale operation is definitely necessary to get the expected result.
The other problem is actually a mathematical issue. It is well known the matrix math used produces a back projection. This artifact has historically been avoided by using a special black and white texture to cut away unnecessary projecting contributions. Using pixel shaders a different approach can be used: a coordinate check is sufficient to discriminate between forward (correct) contributions and backward (wrong, to be avoided) ones.