Hello.

I'm trying to create my own text-rendering engine based on Rastertek's tutorial. The steps I did to make it work:

1. Created my own .png file, containing common ASCII symbols divided by spaces. PNG file had not been compressed.

2. Successfully parsed PNG file so that each symbol has it's own texture coordinates and width/height in pixels. The height is the same for each letter and equals to texture height.

3. Created DDS file from PNG font file.

4. Loaded texture from DDS file.

5. Created squares for each letter according to their width/height in pixels and texture coordinates.

6. Created orthogonal projection matrix to project them on the screen within pixel shader without any changes.

Everything seems well, but the result looks bad:

[attachment=13749:game.png]

As you can see, the letters look dirty and unprecise. Thats how DDS file looks in DX texture tool for comparison:

[attachment=13750:font_dds.png]

Thank you for response, guys.

Out of curiosity, why don't you use the sprite fonts that are part of XNA.

Anyways, I took a look at more detail. I thought it might have been a slightly reduced image, but the final image and the original font both show the Capital 'M' at 10 pixels tall.

However, this looks like compression artifacts. I.e. when it was saved, it may have included a small decompression like PNG/JPG would use. Or it could be from the loading process. I haven't used DX font loading of any type, so I'm not sure exactly how it should work, but that really looks like compression artifacts.

I'm creating my own C++ rendering engine for the sake of learning DX11. Not sure if XNA sprite fonts can be used in such application.

I don't think it is caused by image compressing in my case, since DDS file, generated from image (which I receive uncompressed) looks precise and has no artefacts. However, It is possible that this behavior is caused by loading mechanism. In my engine, I use DDS loader, provided by new Microsoft D3D11 tutorials. I'll create plane with size of the font texture and check if this behavior keeps bubbling up even for sole plane mesh, thanks for pointing that out.

Are you sure of your texture coordinate and your vertex coordinates ? I had a similar issue with OpenGl, and I had to correct the texture coordinates. It was years ago though, so I cannot be more accurate.

Well, I'm absolutely sure about generated vertex coordinates and that I load and set correct texture coordinates from font description file, generated by one of my tools. At first glance, texture coordinates and width of every character, obtained from this tool are legit. The whole mechanism of generating data from PNG file in this tool is just about getting start pixel and end pixel of each symbol and dividing those values by width of the file, so it's pretty clear and simple.

If you paste your two images on top of each other and align the letters it's clearly visible that the rendered characters are wider than those in the texture. Perhaps you scale horizontally somewhere. Also, if you manually specify the back-buffer size, double-check that it matches the window client area.

So you have startPixel/width and endPixel/width OR startPixel/width and (endPixel + 1)/width ?

If you paste your two images on top of each other and align the letters it's clearly visible that the rendered characters are wider than those in the texture. Perhaps you scale horizontally somewhere. Also, if you manually specify the back-buffer size, double-check that it matches the window client area.

Yeah, I just checked font description generation program and it seems that it was (endPixel+1)/width that caused result letters look wider. Anyway, I fixed it, and result text still looks bad:

[attachment=13758:update.png]

Back-buffer's size is okay. By the way, letters on this new screen are 32 pixels tall, so pay no attention to that.