With
sf::Text and
sf::Font SFML offers a clean and easy way to load True Type fonts and show some text on screen.
However, when you want to create some old school like pixel art game using bitmap fonts, you're quite lost.
Using True Type in such situations often looks out of place, even if you're trying to use a bitmap style font. Things never line up perfectly.
If you'd like to use a real bitmap font from a texture, you'll have to implement it yourself (or reuse some existing code).
SFML 3 gives us the opportunity to do something I've been trying to do for a long time: Splitting
sf::Font to have a base class you can derive from. Since this changes the API and breaks existing code, it wouldn't have been that great to introduce it during 2.x.
Here's the basic idea:- Rather than using sf::Font you pick either sf::TrueTypeFont, sf::BitmapFont, or any derived class you create on your own. The rename of the old sf::Font is important to avoid confusion and provide an easier to understand naming scheme.
- Therefore sf::Font is the new name of the abstract base class (similar to sf::Drawable).
- The behavior of sf::TrueTypeFont is 100% identical to the classic sf::Font.
- sf::BitmapFont utilizes image files rather than font files together with a simple mapping.
How would you use sf::BitmapFont?The basic concept is identical to the True Type counterpart, with the minor exception of having to provide a mapping so SFML knows where to find the actual glyphs. This implementation doesn't require any special texture markers. The following interface is subject to change; feel free to suggest changes and improvements.
void sf::BitmapFont::loadFromFile(const sf::String &filename, const sf::String &mapping = "...", const sf::Size glyphSize = {0, 0}, const sf::Size glyphSpacing = {0, 0});
Parameters:- filename: I'll leave this one for you to figure out. This can be any image format supported by sf::Texture.
- mapping: This is a string representing the characters the way they're aligned in the image. Columns aren't separated; rows are separated by line breaks.
Note that this also allows you to map special glyphs or icons (like button images) to Unicode characters. You're also not forced to map every possible codepoint. Invalid ones would be skipped or replaced by the first one.
The default value could look like this:
" !\"#$%&'()*+,-./01234567890:;<=>\n"
"?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^\n"
// ...
- glyphSize: This is the size of individual characters. The default value forces SFML to derive the dimensions based on the image size and character mapping.
- glyphSpacing: This is simply the distance between glyphs in the image (if any). Many premade or generated bitmap font textures come with no spacing or one line between rows and columns. This allows you to load these as well.
Are there any downsides or points not yet covered?- Sure! One popular example would be proportional fonts (i.e. no fixed width). Should SFML support these? If so, how?
- We could make the abstraction generic enough so it becomes possible to also implement something like sf::VectorFont later on. Opinions?
Anything else to keep in mind?Unfortunately there's no standard or most common image format for bitmap fonts, so there's no "TTF" to implement here.
