I don't realise the need about render to texture for strings, but I totally agree with an option to disable text antialiasing. Word wrap/clipping would also be fine but looks more important to me.
The current implementation precaches a limited charset (Latin-1 I think), and optionally you can set your own.
What this does is render all the character glyphs to a texture and afterwards, when rendering, each sf::String character is a quad (opengl jargon) mapped to a portion of that texture.
If I wanted to enable the writing of several languages glyphs (like mandarin chinese, greek, cyrillic, ...):
1. It will use a lot of space saving pre-rendered glyphs
2. They probably wouldn't fit in a hardware supported texture size.
I don't know if this has been asked, but a String that renders to a texture on SetText, instead of having a character set.
And then what? Reload the font file entirely / render glyphs to bitmap / copy pixels to the texture every time SetText is called? :shock:
But I agree, I'll try to remove the charset limitation in SFML 2.0 and make something more dynamic.
The font kept on memory (inside a sf::Font).
Approach 1:Render to bitmap using FreeType and recreate a texture each time the text changes.
Approach 2:Clipping would be mandatory to prepare a texture of good proportions.
Render glyphs to bitmap.
Load the pixels with glTexSubImage2D on the texture you already have (as it's faster than glTexImage2D).
This could implement clipping/word-wrapping or even right-to-left rendering (if needed) directly from FreeType.Previous to rendering, the new string and a cached one should be tested for equality to avoid a costly operation.
Of course this is intended not as a replacement for sf::String, but for a totally different functionality.This wouldn't be intended for dynamic text but for static not-changing-much text.
For example, in an in-game chat you could have a queue with a number of sf::NoCharsetString that have messages from other players, keeping them across each frame, and drawing them (without rendering the font)/freeing after use. The position could be changed without problems.
Also, when using for example 2500 character, you would reduce the triangle use (rendering) from 5000 to 2 (with the texture memory cost)
So, with the speed fact properly documented, it would be a nice adition to the SFML arsenal.
On a sidenote: this could enable all sprite utilities on it, like flipping.
Word wrap/clipping rect would also be really good (for simple GUI rendering).
It's in the roadmap ("clipping masks" or something).
Yes, but I believe it should be together with word wrapping, clipping mostly in a vertical direction, and "newlining" wrapping per words or, if they're too long, per character.
This isn't internationalization friendly (as there are a LOT of rules for word wrapping on other languages) but for half the world that uses a latin alphabet it would be sufficient.
Also I recommend again an option to disable font antialiasing (In FreeType), for pixel-based games. It would be like what "SetSmooth" is to Image, but with the need of re-rendering the charset.
I think that pixel-based games will use pixellated fonts. They render very well in SFML.
Even when using a pixelated font (
Like ProFont) FreeType antialiases the borders.
I've already posted a topic on this.
If you don't want FreeType to do this, when rendering to an image you should pass that you want "monochrome" rendering.
Regards
-Martín
