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.

  • \$\begingroup\$ 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. \$\endgroup\$ Commented Aug 2, 2011 at 7:51
  • \$\begingroup\$ 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. \$\endgroup\$ Commented Aug 2, 2011 at 8:11
  • \$\begingroup\$ I'm doing a PC game, and the font size is set to a whole number. \$\endgroup\$ Commented Aug 2, 2011 at 9:21
  • 1
    \$\begingroup\$ Don't scale texts, create a spritefont for every size you need. \$\endgroup\$
    – Wouter
    Commented Aug 2, 2011 at 12:04
  • 1
    \$\begingroup\$ 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 :) \$\endgroup\$
    – Cubed2D
    Commented Aug 3, 2011 at 16:26

3 Answers 3


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:

pf tempesta variant

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)


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .