-
I've been looking around for a way to combine multiple colors and styles in a single sf::Text. This class (https://github.com/mantognini/RichText) came pretty close, but it doesn't have newline support, which is kind of a deal breaker, so I wrote my own. You can find it here (https://bitbucket.org/jacobalbano/sfml-richtext).
The interface is a direct copy of sf::Text (except for findCharacterPos; I'm not sure how to do this at the moment). It's a drawable and transformable, so you can use it just like any other class.
Currently it has a minimal markup parser built in with support for colors and bold, italic, and underlined text. You can use the built-in color names (includes all the ones that are predefined in sf::Color) or HTML-style hex color codes, and define your own color names as well. The parser could probably use some memory optimization, but it only runs when you set the text, and runs quickly at that.
And here's a screenshot, because everyone loves them. ;D
(https://pbs.twimg.com/media/BEJJodOCUAAP87n.png:large) (https://twitter.com/jacobalbano/status/306888683993321472/photo/1)
-
Sounds and looks great, thanks for the effort! :)
-
That's perfect!
I'm sorry I didn't work to fix the newline bug... I have other projects, and uni (and a job ~~).
-
I just looked quickly through code but I think you made it impossible to have \ in your text(no escaping \ by writing it as \\). And it's c++11 enough to not work with vs 10.
-
I'm sorry I didn't work to fix the newline bug... I have other projects, and uni (and a job ~~).
Hey, no worries! Your class was a good inspiration for me. I doubt I would have thought of storing separate text instances on my own.
I just looked quickly through code but I think you made it impossible to have \ in your text(no escaping \ by writing it as \\). And it's c++11 enough to not work with vs 10.
Yes, it does require C++11. I forgot to mention that. The changes to make it C++98 compatible should be pretty minimal though.
The most recent revision doesn't require a C++11 compatible compiler any more (as painful as it was to give up nullptr).
Nice catch on the backslash thing! I'll fix that right away.
-
And it's c++11 enough to not work with vs 10.
(as painful as it was to give up nullptr).
VS10 supports nullptr, so no need to remove it. ;)
Not sure what FRex noticed that doesn't work with VS10.
-
I used to have auto declarations, initialization lists and a lambda function. I imagine most of those wouldn't be supported.
VS10 supports nullptr, so no need to remove it. ;)
Oh, I didn't know that. I just ended up doing this:
#ifndef nullptr
#define nullptr NULL
#endif
It's probably a horrible hack. ;D Anyway, it compiles with MinGW without -std=c++0x, so it should run mostly anywhere now.
-
nullptr is not a macro (it's a keyword), so with your code it will always be replaced with NULL, even with a C++11 compiler. Just replace every occurence of nullptr with NULL if you really want to write C++-98 code, don't write such ugly hacks ;)
-
Oh :X. I saw that code on StackOverflow (I think), thought "genius!" and stuck it in. That'll teach me. :P
-
Not sure what FRex noticed that doesn't work with VS10.
braced init lists.. ::)
std::vector<int> a={1,2,3,4,5};
And I didn't notice anything, visual did when I wanted to check if \ can be escaped, but it didn't compile and I had little time so I just eyeballed it.
-
Why don't people upgrade to the latest compilers? Come on, they are free, and you don't want to miss the benefits of C++11! Upgrade today! *Microsoft ad plays*
-
Why don't people upgrade to the latest compilers? Come on, they are free, and you don't want to miss the benefits of C++11! Upgrade today! *Microsoft ad plays*
Hahaha, I'd never imagined the day when Tank would make Microsoft ads - but he's right. ;)
(Students even get the Ultimate version for free ;D )
-
I love it! :) This is free to use, right?
Something though, why not add the default font to this constructor like sf::Text does?
explicit RichText(const String& source, const Font& font, unsigned int characterSize = 30);
This way the following is possible.
sf::RichText text("_nice and clean_");
Also, not sure how practical this is but, how about something like:
#rgb(255,0,0) red_text
This is my take on it.
Color
RichText::getColorByRGBA(String source) const
{
//replace all non numeric characters with white-spaces
for (size_t i = 0; i < source.getSize(); ++i)
{
if ( !isdigit(source[i]) )
source[i] = ' ';
}
//split string
std::string part;
std::vector<std::string> rgbValues;
std::stringstream ss(source);
while (ss >> part)
{
rgbValues.push_back(part);
}
unsigned char r = atoi( rgbValues[0].c_str() );
unsigned char g = atoi( rgbValues[1].c_str() );
unsigned char b = atoi( rgbValues[2].c_str() );
unsigned char a = rgbValues.size() < 4 ? 255 : atoi( rgbValues[3].c_str() );
return sf::Color(r, g, b, a);
}
Called here:
Color
RichText::getColor(const String& source) const
{
std::map<String, Color>::const_iterator result = colors.find(source);
if (result == colors.end())
{
//HERE
if (source.find("rgb") != std::string::npos)
{
return getColorByRGBA(source);
}
unsigned hex = 0x0;
if (!(std::stringstream(source) >> std::hex >> hex))
{
// Error parsing; return default
return Color::White;
};
return getColor(hex);
}
return result->second;
}
-
This is free to use, right?
Yep, the license in the readme is the same as SFML.
I'm using the very latest SFML 2.x release and the default font is no longer included. That's the only reason it isn't supported with my class. If you're using a version of SFML that still has it, you can get it like so:
sf::RichText text("_nice and clean_", sf::Font::getDefaultFont());
You could also modify the header to have a default parameter for the font.
#rgb(255,0,0) red text
(snip)
I like that! If you have a Bitbucket account I'd accept a pull request, or I can just add it in myself if not.
-
I like that! If you have a Bitbucket account I'd accept a pull request, or I can just add it in myself if not.
Glad you like it. :) This is my first contribution to a project ever!
-
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 :P ).
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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. :P
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?
-
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 :P
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.
-
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. :P
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.
-
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.
-
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.
-
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.
-
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.
-
I'm not sure if this is my fault or not, but I'm getting this:
(http://i.imgur.com/pXaLx72.png)
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);
}
-
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?
-
Hi,
Nice class. Unicode doesn't work for me (using linux) and I only see squares instead of the normal stuff. I also had to change the end of lines from windows to unix in the source.txt.
Not sure how to deal with that though...
Thanks.
-
I have taken a look at your code, here are some tips, roughly sorted by importance:
- Don't use the namespace sf for SFML extensions -- it might confuse people.
- Consider the rule of three (might be the reason for the mistake mentioned by Raycast). In particular, is there a reason why define the copy constructor? For the destructor, there seems to be none. Always let the compiler generate these member functions for you if possible.
- If you define the copy constructor, don't forget to copy the base classes.
- #ifndef nullptr will not work, since nullptr is no macro. And you are not allowed to define macros with the name of C++ keywords.
- Use the constructor initializer list instead of assignments.
- To avoid the code duplication in the case statements of RichText::setString(), you could use a function.
- With the right literal, you needn't specify the template argument at std::max<unsigned int>(size, 1) -- take std::max(size, 1u) instead.
- If you need string streams to either read or write, take std::ostringstream or std::istringstream.
- Constructors only need to be explicit if they can be called with one argument (but there may be code styles who always write explicit, but then it should also be there for the default constructor).
- Don't mix unsigned int and unsigned.
- Sometimes the return type is on a separate line, sometimes not.
I like the fact that you never use manual memory management and work with STL containers! :)
-
In order:
- Would namespace sfe be more appropriate? That's what the original class used; I wasn't sure if it was the standard for this type of thing
- I don't think there is a reason I defined the copy constructor, actually. I defined the destructor because I thought it would default to private otherwise...is that not the case?
- Good call. I'm going to look into removing the copy constructor I defined anyway.
- Laurent already mentioned the #define nullptr issue. I'll go through and replace them with NULL.
- What is the reason behind preferring the initialization list? I didn't know there was a difference, except when assigning const and reference members.
- Okay. :)
- I didn't know about the u suffix. That's very handy.
- I take it i/ostringstreams are more lightweight than normal stringstreams?
- Good to know. To be honest I'm only using explicit constructors because sf::Text does. ;)
- I thought unsigned int and unsigned were the same. :-\
- Having return types on a separate line is a coding standard of mine in my personal projects. I must have missed a few when I was cleaning up the code.
Thanks for all the feedback! :D
-
Would namespace sfe be more appropriate?
Yes :)
I defined the destructor because I thought it would default to private otherwise...is that not the case?
No, it is public by default.
What is the reason behind preferring the initialization list? I didn't know there was a difference, except when assigning const and reference members.
You express the intent more clearly: Direct variable initialization. When using assignments, you default-construct them (for class types) and overwrite them later. There are many cases where you can't use assignments (no default constructor, base classes, constants, references, non-copyable and non-movable types), so I recommend to be consistent. Especially since assignments don't bring an advantage, unless you actually need delayed initialization.
I take it i/ostringstreams are more lightweight than normal stringstreams?
Slightly, and again you express more clearly that only either input or output is required. If you accidentally call an operation of the other kind, the compiler yields an error. Of course, it's not a big issue, but it doesn't cost anything (except thinking 5s about what is needed) ;)
I thought unsigned int and unsigned were the same. :-\
They are, but you should use one of them consistently in your code. Just a matter of code style, again no big issue.
-
Somebody (I don't remember who...) one the wiki once used the namespace sftools:: for classes like this. I don't want to start a discussion on what's more suitable. I just found that it clearly states, that it's not part of SFML. So I thought I throw it in there if you still look for one.
-
Great class Mr. Roque. Its amazing what you have done. Only problem is text wrapping.
I am actually observing your code, editing the style, using newer cpp constructs like for each loop and such. Removing unneeded if statements, compacting the code, and compiling along the way to ensure it is the same results. All with the aim to add text wrapping.
Note that SFML should do better. It is nearly version 3 and they still havent added text wrapping and rich text directly in the library. They should look at the android graphics api, TextView, ListView, and such. These are regularly used ui constructs!
I am here on my Windows XP, no graphics acceleration, and finding it hard to write a simple ui. I am working like 4, 5 days and cant pass the ui stage. A ChessBoard, with pieces, movable, with 2 Text Box Fields.
Started using GDI, studied it in one day, then another day to devise a design structure for it. Then came to a dead end, when I ready to add the pieces, which NEED transparency.
So I began studying OpenGL. OpenGL and DirectX I studied in the past but failed to create any app with them. Now studying it again I was once again overwhelmed! Managed to set up the Context. Studying GDI elevater my understanding. But all I did was draw a rectangle and make it spin. I realized immediately I would have problems loading textures{chessboard, chesspieces}, and Object orient them like what I did with GDI; by giving each object a mem_ctx; Worse of all, OpenGl and GDI werent compatible, unless I want SlowGL. And how to render text with OpenGL????? 1.1 ????
I had to say later to OpenGL and reconsider GDI+ which I read was slow. After all DirectWrite and stuff is vista and up. I was staying away from SFML because I mastered it already. I created a draugh game and Chess game with it already. I wanted to grow my knowledge to the lowerlevels of graphics. I tried GDI+. Surprisely I never used it before in the past. I was gravitated by the advertisement of it on MSDN. Even though the documentation of it is well less than GDI, it was breath taking. They told you how much it has improved and improved and improved over GDI. When I checked it out, my heart sank. It literally tooks SECONDS for GDI+ to draw 8 Chess pieces. It really should be called GDI-; Why it has to be software implemented I dont know! But it is TOTALLY UNUSABLE on my machine.
So, out of desperation, I had to use SFML; my old friend. The one that taught me graphics programming. SFML 2.5.1.
It took me some time to install it. Only sfml as a library, tells you to give the linker symbolic names. sfml-graphics. There is no lib file called that. But now I know I can bypass setting lib directory, and simply selected the real lib file! Or I can do it how SFML says. either way.
But my real problem with SFML is the dll. What is the purposed of shared libraries if you cant share them! Why must I recopy those file into every app directory? They should be located from a centralized path, that one file can be shared. And finding and copying the files is simply troublesome. Especially when Sfml asks for dll not created by sfml. such as libgcc.
Anyhow, I finally got sfml working. Begin creating my drawables. Then another dead end. SFML does not do textwrapping. This is stupid! Performance wise, it best sfml does the drawing and wraps text in the iterations. Rather than have us use calculateCharacterPos which I am sure does an iteration on every call. Also sfml doesnt support editable text. Again take a page from Android! Lucking they provide a const sf::String& which is safely casted to non const.
Great. I can wrap text now. Then when I look at my use and the text looks bland. If only I could draw red text and then white text. Then it came to my realization that this wasnt going to be my easy moment. I thought about it and found nothing good.
So I tried back GDI as it is compatible with SFML. DrawText does textwrapping, but no rich text. GetTextExtentExPoint32 promised to give me measurements but was very cumbersome! TextOut can do rich yext but no text wrapping. And I could maths out how to do my everythinh any of these graphics engines.
To do rich text in a console app is very easier. For example, syntax highlighting. Why is the real graphics engines not allowing me this ease. And again, I am no where near learning to draw text with OpenGL.
Luckily I found a library on the internet that Roque metioned. Unfortunately I never got it to work. And it is not very very rich rich text. for example, he was exploding texts into Lines. So a line can only be in one color. Not enough for syntax highlighting or my needs. But I loved how he used the stream operator to stream in the state of the text and stuff.
Needless to say, I couldnt implement his idea. So I searched again and saw Roque's library. and got it working. And it was more beautiful than the illustration on the Net.
Thank you Roque. But SFML needs to do better! They should implement a TextBox, with text wrapping and rich text abilities. It makes no sense I am creating 50 sf::Text to display one string.