Hello, I made the patch originally,
From what I remember when making this,
DrawPrims() loads appropriate shaders and makes the D3D Draw calls onto the rendertarget (with a given texture and primitives buffer).
StretchRect() is just a native D3D function to resize and copy a texture.
rt is the rendertarget and tex is a working copy of the rendertarget from previous calls (in this case).
FBP I dont understand so well, but if you look at other game-specific hacks in GSdx, it is often used to target a specific render point.
With enthusia (probably all games), most of the Draw calls are made on a strange sized rendertarget before finally being resized to fit the window.
Now as to what is cause the vertical lines in DrawPrims(), this may not be true, but I believe it is a float to integer conversion error (eg; 126.5 converts to 126 instead of 127 somewhere) when the shader is resizing final rendertarget result to the correct size. The other possibility is a floating-point precision error. (due to the scale values being so small)
I avoided this by using StretchRect to stretch/resize the working copy to the rendertarget, in replacement of the shader doing the stretching.
1024/256 multiplied by the rt scale value seems to replicate what the shader was suppose to resize it to.
Basically the shader stretching function has a bug, not sure which shader or why.. but it seems to be the last draw call before the rendertarget is Present()'d to the backbuffer.
Also a quick tip, I used
NVIDIA PerfHUD to track down the exact point the black lines were introduced. It allows you to view the rendertarget after each draw call.
Hope this clears things up and looking forward to seeing an official patch!
