This is a native Direct3D 11 implementation of a bitmap font renderer, similar to the SpriteFont type from XNA Game Studio, plus a command line tool (MakeSpriteFont
for building fonts into bitmap format. It is less fully featured than Direct2D and DirectWrite, but may be useful for those who want something simpler and lighter weight.
SpriteFont is particularly useful for the Windows phone 8.0 and Xbox One XDK platforms that lack support for Direct2D and DirectWrite
The SpriteFont class requires a
instance and a .spritefont bitmap file.
std::unique_ptr<SpriteBatch> spriteBatch(new SpriteBatch(deviceContext));
std::unique_ptr<SpriteFont> spriteFont(new SpriteFont(device, L"myfile.spritefont"));
For exception safety, it is recommended you make use of the C++ RAII pattern and use a std::unique_ptr or std::shared_ptr
spriteFont->DrawString(spriteBatch.get(), L"Hello, world!", XMFLOAT2(x, y));
The Draw method has several overloads with parameters controlling color, rotation, origin point, scaling, horizontal or vertical mirroring, and layer depth. These work the same way as the equivalent SpriteBatch::Draw parameters.
SpriteFont has three constructors:
- Pass a filename string to read a binary file created by
- Pass a buffer containing a MakeSpriteFont binary that was already loaded some other way
- Pass an array of Glyph structs if you prefer to entirely bypass MakeSpriteFont
In addition to DrawString
with various overloads, SpriteFont includes the following helpers:
- MeasureString which returns the size of the given string in pixels.
: The string size is computed from the origin to the rightmost pixel rendered by any character glyph. This has the effect of ignoring 'trailing spaces'. See work item 674 for more details.
- ContainsCharacter tests to see if a given character is defined in the font
If you try to draw or call MeasureString
with a character that is not included in the font, by default you will get an exception. Use
to specify some other character that will be automatically substituted in place of any that are missing. You can also use
to obtain the current default which is also defined as part of the font.
SpriteFont will respect new line characters (\n - ASCII character 10), and ignores carriage returns (\r - ASCII character 13).
There is no special handling for the bell character (\a - ASCII character 7), backspace (\b - ASCII character 8), horizontal tab (\t - ASCII character 9), vertical tab (ASCII character 11), form feed (\f - ASCII character 12), or escape (ASCII character 27).
These are all treated as standard characters and if it is missing from the .spritefont, they will all render as the default character.
This implementation supports sparse fonts, so if you are localizing into languages such as Chinese, Japanese, or Korean, you can build a spritefont including only the specific characters needed by your program. This is usually a good idea for CJK languages,
as a complete CJK character set is too large to fit in a Direct3D texture! If you need full CJK support, DrectWrite would be a better choice if available on your target platform. SpriteFont does not support combining characters or right-to-left (RTL) layout,
so it will not work for languages with complex layout requirements such as Arabic or Thai.
The default character region for
from 32 to 127 covers the standard 7-bit range. For example, here is a C++ Unicode string for the printable characters (this would be an ASCII string if you remove the L prefix).
If you are wanting to render an 'extended ASCII' string with SpriteFont, you need to capture the full set of characters which are not contiguous in Unicode (see
for details). You then need to convert your 'extended ASCII' string to Unicode before calling DrawString.
if (!MultiByteToWideChar(437, MB_PRECOMPOSED,
spriteFont->DrawString(spriteBatch.get(), unicode, ...)
For example, here is a C++ Unicode string with the full extended ASCII IBM PC character set from 128 to 255:
Xbox One exclusive apps MultiByteToWideChar does not support codepage 437.
The Sprite Font implementation is compatible with all feature levels. The primary limitation is on the size of the sprite sheet texture which should fit into the limits for known feature levels (i.e. to support all feature levels, it should be no larger than
2048 x 2048).