# How do I get beautiful small text in XNA without using external libraries?

In XNA, the spritefont technology is horrible. Nuclex does the job so much better, but I don't want to have any external references, and I'm nearly done with my game.

When using fonts like Sansation or Quicksand, it looks terrible in smaller sizes of the fonts. It's so bad!

Is there a known workaround for this? I tried setting the fontsizes to extremely high, and then scaling them down in the spritebatch with no luck.

• I use SpriteFont to create my fonts for XNA, you have lots of flexibility. I also make sure that the font's position is an integer so that no nasty antialiasing occurs, but this is probably not a great solution. You could try point filtering in your text spritebatch calls too. Aug 2 '11 at 7:51
• Don't forget to test your small fonts on a variety of real devices and people. If it's a 360 title and thus targetting TVs, the sizes of all visual elements tend to need to be a fair bit larger than on a PC screen. Aug 2 '11 at 8:11
• I'm doing a PC game, and the font size is set to a whole number. Aug 2 '11 at 9:21
• Don't scale texts, create a spritefont for every size you need. Aug 2 '11 at 12:04
• Some more rules for you here. Clamp the position vector to integers before rendering, otherwise sampling will make your output text look rubbish. Might be worth changing the texture sampler to Point/Nearest Neighbor before rendering text. Especally if your font is pixelated :) Aug 3 '11 at 16:26

XNA lets you import a texture as a spritefont. You can probably get better hinting and anti-aliasing in your font if you lay each character out manually in a good image editing program, rather than relying on the sprite sheet that XNA generates.

The XNA sprite font processor uses DXT3 compression that does not work well with the new premultiplied alpha in XNA 4.0. Hence the blocky look of the text.

The Nuclex sprite font processor outputs exactly the same data, except that the internal Texture2D that holds the font bitmap data is not compressed - so it has no quality issues.

Because the data from the Nuclex processor is in the same format, the XNA SpriteFont reader can read it, and you do not need to include any Nuclex libraries for distribution with your game.

(It also conveniently allows you to use the same XML format as XNA's native sprite font definitions.)

That being said: there's nothing wrong with bundling external libraries with your game. It's not like they get installed on your system or anything. (You could even go so far as to merge the two assemblies).

And the same thing goes for the code (if you're worried about version control, for example). You can just put Nuclex.Fonts.Content.TrueTypeImporter.dll in with your source code. It's actually not a big deal.

You could use pixel fonts:

When you use a pixel font at the font size it was designed for (or a whole multiple of it, e.g. 2x, 3x, 4x) you are guaranteed pixel-perfect text that requires no anti-aliasing. This means you never have to deal with the terrible anti-aliasing which makes XNA's sprite fonts so bad and Nuclex so much better. (This article examines that problem and compares them)