No SFML doesn't do any batching. One can reduce the draw calls by using vertex arrays.
Hmmm I guess draw calls aren't that evil then
Probably because the only use case for it would be a part of an existing HTML page that should be drawn with SFML. However, parsing only colors and formattings, one is still too limited to actually display even a simple HTML page. Additionally, websites usually define the layout in the CSS, not HTML document.
Using HTML tags voluntarily for graphical applications doesn't make any sense -- the syntax is extremely verbose (you always need two tags for each formatting, and each tag consists of many characters). In contrast, the compact syntax proposed by TechRogue is very handy, as it still leaves the text readable.
Oh, by all means, I never actually meant implementing the HTML parsing/drawing. Even doing it partially would be quite hard (let's just leave that stuff to the guys at Google and Mozilla
).
And I do agree that the characters TechRogue chose are quite damn good (not often used and do kind of hint to what they're supposed to do, like the underscore for the underlining).
What I meant is to have the opening/closing tags, since, well, they just work.
Especially in situations when you're inserting for example a sting into another like so:
string1 "#orange Inserted String" +
string2 "#green Original String Start ... End" =
endString "#green Original String Start #orange Inserted String End"
As you can see the "End" stays orange colored. This could be very easily avoided by using the closing tags.
Also the BB-like syntax with "[]" would prevent the need for escaping characters.
Very bad idea. If you want this class to be used by other people, you cannot just modify SFML. No one will download your fork only for such a class, all the more if he cannot be sure what other code you broke with your "hacks".
Just use the abstraction mechanism SFML provides, and trust in Laurent to have spent some time on how to make rendering fast. You won't simply outperform SFML in a few minutes, especially not without violiating other design decisions. Concretely, this case amounts to sf::VertexArray.
I do agree on this point. Hacking stuff in programming is generally bad. But it works.
I tried "hacking" the Text class to enable a bitmap font, using memcpy and so on. It was extremely ugly. But it worked.
As for being used by other people, that's not really an issue for me.
I think I'll require a special Text class for my GUI system anyway, so it will be useless for other people.
But if it can be profitable for everyone, why not?
I believe SFML 2.x uses vertex arrays to do text drawing anyway. Granted, drawing each chunk of text separately (as my class does) negates some of the benefit, but it should still be quite fast.
Using a single vertex array would be quite simple, but you need to copy and modify the source code of sf::Text.
This would be quite nice
Especially if it would be added to SFML afterwards.
But what about using multiple fonts in one vertexArray?