   Why doesn't this work: Shaders and Drawing Text
  I like to think my text engine is a neat little one. You have a bitmap with the ascii letters arranged so that you can just do some quick division and modulus' to get texture coordinates for each letter. It keeps an std::vector with all the text strings you have 'registered', after you make a string, you get back an interface object. All you have to do to remove your string is destroy the object. You can use it to move it around and change the contents of the string and what have you.That is just a sort of precursor to my problem. I wrote it with DirectX FVF before, and it worked fine, but I switched over to using vertex and pixel shaders, so I can do cooler things with it, like set the color (white text on black background, multiply by the color in the pixel shader, use additive blending.) But it's just not showing up.How I have it set up is that the top left corner of the string is at (0,0). Each letter goes in the positive x direction, and new lines go down a bit in the positive y. Which should work like screen coordinates. Z and W for the position coordinates are set to 1.0f. What I believe should work is simply add a vec4, ie one slot of the shader's floating point constants, to the verticies. If the top left corner is at (0,0,1,1) (I don't think the z and w coordinates really matter but they're one anyway) and I add, say, (5,5,0,0) to that, the string should be transformed so the top left corner is at (5,5) in screen coordinates. No matrix transformation needed, making text drawing very fast.But... it just doesn't work. I don't see anything. Perhaps it has something to do with the Z and W of the verticies being 1.0f. Maybe it's that I'm overlooking something with my vector-instead-of-a-matrix plan. I'm sort of at a loss. Just for fun I let it use the world-view-proj matrix of the last object I drew, which was still sitting in the floating point constant register, and it displayed correctly as a 3d object chilling out upside down going off into the distance. So it's not like there's anything wrong with the vertex buffers or anything of the sort. The only thing I changed from it's fully working, FVF version, is swapping it out for shaders, and my little vector trick.Any ideas?   
  The Z coordinate of 1 is probably the problem.  After the homogenous divide by W (also =1), your left with 1 which is right on the boundary of being discarded.  In my own text rendering code 1 use Z=0.5 and W=1 (with Z test disabled), which works fine for both OpenGL and Direct3D.This is the Cg vertex shader code i use,struct Input {    float2  position    : POSITION;    float2  uv: TEXCOORD0;};struct Output {    float4  position    : POSITION;    float2  uv: TEXCOORD0;};Output main( Input IN, uniform float2 _HalfResolutionInv, uniform float2 _Position0 ) {    Output OUT;    IN.position.xy += _Position0.xy;    OUT.position.x = IN.position.x *  _HalfResolutionInv.x - 1;    OUT.position.y = IN.position.y * -_HalfResolutionInv.y + 1;    OUT.position.z = 0.5;    OUT.position.w = 1.0;    OUT.uv = IN.uv;    return OUT;}_Position0 is the offset vector like in your own code ( (5,5,0,0) in your example )._HalfResolutionInv is ( 2/xSize, 2/ySize, 0, 0 ).IN.position is the screen coordinates for the vertex in pixels.;  From what I understand, you're putting the screen coordinates from 0-800/0-600, for example, to (-1)-1/1-(-1). I'm sort of confused as to why. Doing some reading lead me to this page, which about halfway down does your algorithm, but backwards. Something to do with something, it doesn't go into much detail about it.Either way, it doesn't seem to work. I make a note to turn Z test off ( D3DRS_ZENABLE to D3DZB_FALSE, right? ), just in case it is doing something annoying to it, and it still does not work.I uploaded my code to my webspace, if you want to take a look. It's only 4k and shouldn't be too hard to understand. Pardon any messiness, there shouldn't be a lot but it'll be squeaky clean once the thing works. Also pardon the color information being in the vertex. It would work a million times better being a simple constant floating point register value, and such was what it originally was. Moving it to the vertex was one of the things I tried to do to fix this problem, and I plan on moving back once I get this settled.   ;  This is probably off topic, but don't forget that Unicode exists out there. Implementing proper multilingual support will help you greatly if you ever plan to internationalize you application.The world out there isn't just ASCII :)   ;  Noticed a typo in your vertex shader code, Kimani,  "add r0.y, r0.y, c1.x"should be  "add r0.y, r0.y, c15.w"The reason the X and Y coordinates are transformed to the range [-1,1], with (-1,-1) being the top left corner of the screen, and (1,1) being the bottom right, is that the range of values for clip space (in Direct3D) is (-1,-1,0) to (1,1,1).The output position from the vertex shader is transformed into clip space by dividing the X,Y and Z components by the W component (the homogenous divide).  Because we are setting W=1 in the vertex shader, we need to set X and Y to the ranges [-1,1].;  For Unicode, theres a tutorial at NeHe that gives a good intro to using the FreeType library to render fonts into textures,http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=43All the tutorials over at NeHe are OpenGL rather than Direct3D, but should still be helpful.The tutorial renders each glyph to a different texture (which is definately not the best way of doing things!).  If instead you render all the glyphs to a single texture, then it should be fairly straight forward to integrate with your current code.;  Everything seems to be working now. After I fixed them typos and played around for a while, it would seem Direct3D is a little confused as to what counter clockwise means (which it most definitely is wound in). Turning off backface culling did the trick.I'll take a look at the Unicode things. It's not a problem to add different characters onto the texture, so it wouldn't be hard to make it work, it would just be tricky to work with. You can't just get a string and use it's char/int values straight off the bat if you're throwing in extra characters here and there.   ;  Direct3D culls counter-clockwise faces by default, so if you're winding them in CCW order and using the default D3D culling setting, that's why they're not showing up.   