New RichText class

[Vovosunt]

It constantly makes me wonder, why doesn't anyone make a Richtext format with BB/HTML-like code support.
It shouldn't be hard (maybe, once I overcome my laziness I'll do it myself ).

Job well done nonetheless.

BTW does anyone know if there's some sort of draw call batching behind SFML code?
I've done some tests with draw calls and didn't see much of a difference.
And looking through the SFML source didn't reveal anything either.
Draw calls should be expensive right?
I would try hacking the SFML Font and Text to be able to draw everything in one call and maybe enable bitmap-fonts.

[eXpl0it3r]

BTW does anyone know if there's some sort of draw call batching behind SFML code?

No SFML  doesn't do any batching. One can reduce the draw calls by using vertex arrays.

[Nexus]

It constantly makes me wonder, why doesn't anyone make a Richtext format with BB/HTML-like code support.

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.

I would try hacking the SFML Font and Text to be able to draw everything in one call and maybe enable bitmap-fonts.

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.

[TechRogue]

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.

[Ceylo]

What would be great would be supporting (even only a subset) real RTF syntax. This would allow anyone to export its text to this format or write it in his/her favorite editor. Plus it does not involves the same issue as HTML about CSS definitions. Your syntax is fine for small tests but what if you want to display a full license with highlighted parts for example?

If you agree with that, then librtf seems to be a good candidate for this support (I'd done some testing with it). I could help at bringing this support if you wish so.

[Laurent]

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.

[Vovosunt]

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?

[Laurent]

Hmmm I guess draw calls aren't that evil then

They are, since performances directly depend on the number of draw calls.

Especially if it would be added to SFML afterwards.

Nope

But what about using multiple fonts in one vertexArray?

The main limitation when using a vertex array is that you can only use one texture when drawing it (just like any other SFML entity). Each font has its own glyph texture, and worse, each character size within the same font has its own texture. So you have to use at least one vertex array per font and character size.

[TechRogue]

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.

If the markup were to use BBcode you would end up with something like this:

string1 "[color=orange]Inserted String[/color]" +
string2 "[color=green]Original String Start ... End[/color]" =
endString "[color=green]Original String Start [color=orange]Inserted String[/color] End[/color]"

Theoretically I could manage color state with a stack, but nesting tags like that makes me skittish . Parsing BBcode would be a lot more complicated than what I'm doing now, too.

You'd still need to escape characters; they would just be a different set. '[' and ']' would have to be escaped, at least.

But what about using multiple fonts in one vertexArray?

The main limitation when using a vertex array is that you can only use one texture when drawing it (just like any other SFML entity). Each font has its own glyph texture, and worse, each character size within the same font has its own texture. So you have to use at least one vertex array per font and character size.

This is the reason my class only supports a single font and character size per instance. I thought about having a font keyword and a registerFont(name, font) method, but the implications terrified me. 

What would be great would be supporting (even only a subset) real RTF syntax. This would allow anyone to export its text to this format or write it in his/her favorite editor. Plus it does not involves the same issue as HTML about CSS definitions. Your syntax is fine for small tests but what if you want to display a full license with highlighted parts for example?

If you agree with that, then librtf seems to be a good candidate for this support (I'd done some testing with it). I could help at bringing this support if you wish so.

The idea of writing using a rich text editor instead of writing markup is definitely appealing, although I'm hesitant to require a (relatively) big dependency like librtf. Maybe we could make a new class (sf::RTF?) based on my RichText class that would support a good amount of RTF syntax.

On that note, what type of subset are you thinking of? Supporting multiple fonts and character sizes could be tricky. A simple test document I just made includes references to Times New Roman, Arial and Mangal, and I'm only using Times.

[Vovosunt]

If the markup were to use BBcode you would end up with something like this:

string1 "[color=orange]Inserted String[/color]" +
string2 "[color=green]Original String Start ... End[/color]" =
endString "[color=green]Original String Start [color=orange]Inserted String[/color] End[/color]"

Theoretically I could manage color state with a stack, but nesting tags like that makes me skittish . Parsing BBcode would be a lot more complicated than what I'm doing now, too.

You'd still need to escape characters; they would just be a different set. '[' and ']' would have to be escaped, at least.

Well how about #color and /# then?
I mean, what's so difficult about a stack?
(You'll need only one for colors; bold, italics and underline can be kept as bools).

On that note, what type of subset are you thinking of? Supporting multiple fonts and character sizes could be tricky. A simple test document I just made includes references to Times New Roman, Arial and Mangal, and I'm only using Times.

Well you're using separate Texts already, so why would it be difficult?
Something like & for size and @ for Font should work.
Sizes should work just like everything else but you'll need a map for Fonts.
If you want to batch the Texts by Font and Size you could, again use a map or some sorting algorithm.

[TechRogue]

Well how about #color and /# then?
I mean, what's so difficult about a stack?
(You'll need only one for colors; bold, italics and underline can be kept as bools).

It's not that a stack-based system would be difficult to implement. The problem in my example is that it isn't clear what the closing [color] tag belongs to. Nested colors make no sense, whereas nested formats do.

Sorry, but this isn't something I'll consider adding. Feel free to build on my implementation to add a BBcode parser if you want to, though.

[snip]
A simple test document I just made includes references to Times New Roman, Arial and Mangal, and I'm only using Times.

Well you're using separate Texts already, so why would it be difficult?

I don't think you understand. The .RTF file I just made references three different fonts, but all of the text in the document is in one font. If we were to support the entirety of the RTF syntax, all referenced fonts would need to be loaded into the program, and it isn't clear which ones are required without looking at the document source.

[Ceylo]

The idea of writing using a rich text editor instead of writing markup is definitely appealing, although I'm hesitant to require a (relatively) big dependency like librtf. Maybe we could make a new class (sf::RTF?) based on my RichText class that would support a good amount of RTF syntax.

Actually librtf is so small that you can include all of its files directly in your project without caring about any setting. And yes it could be built on top of your class, but there are a few odd points in it. It lacks documentation, and I've been wondering what's the difference between the "source" and "string" Strings you use.

On that note, what type of subset are you thinking of? Supporting multiple fonts and character sizes could be tricky. A simple test document I just made includes references to Times New Roman, Arial and Mangal, and I'm only using Times.

Well... nothing more than what you already support with your current class. But I hadn't noticed one couldn't have different character sizes or fonts. At least different sizes would be a good point.

As for the different fonts, yes you may need a lot of them, but the interesting point would be being able to load the system fonts as soon as they're required. That's what a RTF editor does, it'll allow you to set a font according to the ones already installed, not according to a font file you'd have to choose.

[TechRogue]

Yeah, I badly need to add some implementation comments. The "source" string includes the markup characters, so everything can get rebuilt when the character size or font changes. The "string" string contains just what you see on the screen.

[Raycast]

I'm not sure if this is my fault or not, but I'm getting this:




Related code snippet:

std::vector<sf::RichText> textList;

textList.push_back(sf::RichText("*bold*, ~italic~, _underlined_", debugFont, 32));
textList.push_back(sf::RichText("unicode: áéíóúçÆæÞðë", debugFont, 32));
textList.push_back(sf::RichText("#red red, #green green, #blue blue", debugFont, 32));
textList.push_back(sf::RichText("#ff6600 sexy #33ff99 hex #9933ff code #ff33cc support!", debugFont, 32));
textList.push_back(sf::RichText("#ffff33 ~*_EVERYTHING AT ONCE :D_*~", debugFont, 32));
textList.push_back(sf::RichText("#white Escaping format characters is supported: \~\*\#\_", debugFont, 32)); //This line triggers "Debug Assertion Failed! Line:1675, Expression: string subscript out of range."

for(int i = 0; i < textList.size(); i++)
{
        textList[i].setPosition(4, i * 45);
        engine.window->draw(textList[i], sf::RenderStates::Default);
}

[TechRogue]

Sorry for taking so long to reply. My internet access has been dodgy the last few days.

I remember seeing this same behavior, but I thought I had fixed it. Do you get the same result if you just draw one of the offending lines on its own, without pushing it into the vector?