font texture artifacts

07b9e9e8483468e4a0e1bac1843e6e74
0
Snoob 105 Jan 02, 2013 at 23:05 c++ directx

I’ve implemented a FreeType font renderer. Using OpenGL anything looks like expected, but when I try to render same text with Direct3D9 i got some texture artifacts.
The text looks like cut of at bottom and some letters contains texture fragments at the border edges:

http://s7.directuplo…7c6y54l_jpg.htm Test text rendered with OpenGL

http://s1.directuplo…2ksd9fy_jpg.htm Test text with artifacts rendered with Direct3D9

I use Bilinear filtering (linear/linear/point) and set UV texture addressing mode to CLAMP. First I thought there may be addressing failures and also test
WRAP and BORDER, but I got same issues.

The letters I use for text rendering are rendered to an atlas texture. Could it possible I got those artifacts while I do not use padding space between
the lettes in this atlas texture? If it so, why only on D3D9? Any ideas what could be wrong?

5 Replies

Please log in or register to post a reply.

A8433b04cb41dd57113740b779f61acb
0
Reedbeta 167 Jan 02, 2013 at 23:56

Seems like you may be getting bitten by the infamous half-texel offset of D3D9. See this MSDN article for details - the upshot is you have to adjust your UVs by half a texel to make them line up correctly with screen pixels. In D3D10-11 they fixed this so it works the same way as OpenGL does (also known as the correct way. :D)

07b9e9e8483468e4a0e1bac1843e6e74
0
Snoob 105 Jan 03, 2013 at 12:45

Thanks for your advise. I’ve to check this.

07b9e9e8483468e4a0e1bac1843e6e74
0
Snoob 105 Jan 03, 2013 at 20:25

As promised I’ve checked your advise and it solves the problem! Reedbeta thank’s again for your help, you protect me from sleepless nights ! :D
Just one more question concerning to the half-texel offset:

I have read a couple of articles that describe the necessity to move the texture one half unit of the vertex positions in order to get the correct mapping between texels and pixels. According to DirectX documentation, offsetting by half a pixel is only necessary “when rendering 2D output using pre-transformed vertices”. But how I could figure out that I’ve got pre-transformed vertices? On vertex buffer declaration I do not use the FVF flag. So I get into trouble if I always try to fix the half-texel offset by adding -0.5 to x and y values of the vertices (especially using OpenGL).

A8433b04cb41dd57113740b779f61acb
0
Reedbeta 167 Jan 03, 2013 at 20:59

I think by “pre-transformed” vertices it just means vertices that are in screen space already, such as the quads for text. Another common case is when doing a full-screen pass for postprocessing. When rendering 3D stuff you don’t typically have to worry about it.

07b9e9e8483468e4a0e1bac1843e6e74
0
Snoob 105 Jan 04, 2013 at 09:09

Screen space only, sounds easy to fix. Thanks again.