Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What if I have an arbitrary renderTarget, that is smaller than the screen (say it is 1x1 pixel) and I want to make sure in the VertexShaderFunction that all my pixels end up exactly in that 1 pixel region? No matter what I do, they all seem to get culled at some point, though GraphicDevise.Clear() works OK.

Where is the top left corner of the renderTarget Vertex-shader-vise? I tried output.Position = (0,0,0,0)/(0,0,0,1)/(1,1,1,1)/(-0.5,0.5,0,1) NOTHING works!

Fullscreen quad is not an option 'cause I actually need to process geometry in the shaders to get the results I need.

share|improve this question
This won't work. A vertex shader doesn't have a concept of "pixels" or even "triangles". If you move all the vertices into one place you will get no output. If you spread the vertices out (somehow - it would be very convoluted) - then you've just ended up with a full-screen quad. – Andrew Russell Jul 28 '13 at 13:27
ok that's what I need - I need to save original vertex info to compute screen position, but I need to "spread" the vertices to get the fullscreen quad. – cubrman Jul 28 '13 at 13:29
The simplest way to do that is to probably create a second version of your mesh. Duplicate vertices - 3 per triangle - no index buffer. For each vertex, also store an appropriate vector so that each triangle has both its original coordinates, and coordinates to cover the screen (full-screen-triangle: so its vertices extend beyond the screen edges). Like I said: convoluted. You almost certainly do not want to do this. Like I said on your previous question on SO - you're asking detailed implementation questions for an approach that is fundamentally flawed. Ask a higher-level question. – Andrew Russell Jul 28 '13 at 13:43
maybe u r right, it's just very attractive an idea u know). Will be sure to try this thing. BTW How would I pass those extra vertices to the shader? – cubrman Jul 28 '13 at 14:01
Probably in POSITION1 (MSDN). On the XNA side you need a custom vertex format; set VertexElement.UsageIndex to 1. – Andrew Russell Jul 28 '13 at 14:19
up vote 0 down vote accepted

If anyone is reading this, there is a way to control pixel position in the vertex shader, ofcourse :). But you need to remember two things:

1) if all vertices end up in the same position - no pixels will be drawn, so you must specify a region between at least 3 dots;

2) the GPU will interpolate the region you entered across your rendertarget, minding the latter's size, so in the end for every triangle you draw, only one pixel will get drawn for pixel slot in the rendertarget. So two pixels will end up in the same spot fighting for it ONLY IF they belong to two different triangles.

One more thing I wanted to add. I was asking this question as I had an idea about a pixel-perfect collision detection system in 2d world FOR A NON-PIERCING BULLET (the piercing one can be easily implemented with occlusion query and stencil buffer). I dropped the idea as it's solution was infeasible and inefficient. However, there is one approach one could theoretically employ. You don't even need DX10/11 for this. The thing is, if you have your scene with monsters drawn into it using their numbers and not colors, and it you then use this scene as a texture in a shader, you can paint a bullet over it and compute where it hits the monsters. Each pixel will even know WHICH monster it hit, and you can even compute the difference from the end of the barrel to the pixel. However, you will end up with a tone of pixels and won't be able to tell which one is the first one in the bullet's way. To solve that, you can take call tex2D() in each pixel's shader multiple time IF you can compute the UV offsets for EVERY pixel of the bullet's trajectory. Then each pixel will know it's hit data, and the data for neighboring pixels and output only the data for the nearest hit. Thus you will end up with a line that consists of several blocks of pixels. In that case you will need to run the shader one more time to refine it to a line consisting of pixels each of which has the same data - which monster is the first one to hit. Then you simply call Texture.GetData for a single pixel region and end up with a monster number. If you will make a call in a different thread - you can read data later without program stalls.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.