Messages

1

Feature requests / Re: Add sf::String::at(), analagous to std::string::at()

« on: July 23, 2016, 08:05:57 pm »

Just as a tiny suggestion. You could just use std::string instead of sf::String for string storing/manipulation.

And SFML could do that too, but there's a good reason it doesnt, so I don't either

It's a questionable way of error handling, like checking every pointer against null before dereferencing it, or checking divisors against 0...

Reasonable implementations of the STL (which is used internally by sf::String) provide you with assertions for such cases. They show you all your logic errors when debugging, but you get full speed in Release mode and don't need to clutter code with try-catch blocks, to which you can't even meaningfully react, as the bug shouldn't exist in the first place.

That would be great!
All I am saying is this code should break:

sf::String s("A");
std::cout << s[1] << std::endl;

2

Feature requests / Re: Add sf::String::at(), analagous to std::string::at()

« on: July 10, 2016, 06:30:47 pm »

The same as for sf::string::at(). Does a range check and throws an exception in case of violation. My use case exactly? Well, I am writing a program that uses SFML and I am drawing out arrays of sf::Strings (and modifying those strings too) and using at() would have already saved me some crashes.

3

Graphics / Re: Mixed styles in one sf::Text object

« on: July 10, 2016, 05:53:49 pm »

eXpl0it3r, thanks for the link, I will check it out!

4

Feature requests / Add sf::String::at(), analagous to std::string::at()

« on: July 10, 2016, 05:40:14 pm »

The title has it
That's what happens when you don't follow guidelines 
https://github.com/SFML/SFML/issues/1110

5

Graphics / Re: Mixed styles in one sf::Text object

« on: July 10, 2016, 02:47:06 pm »

Thanks for reply I thought about that too, turns out it is even slower (http://en.sfml-dev.org/forums/index.php?topic=20485.0). But piece-by-piece stylization will work anyway.

6

Graphics / Mixed styles in one sf::Text object

« on: July 10, 2016, 09:44:11 am »

So I have this string which I have to display and some characters in it may be of different styles than other characters. Something like this:
SFML String
This is one sf::String and I need to draw it. But as far as I can see, sf::Text does not allow for character-based style change.
So, what would be a good (and efficient) way pull it off? For once, I could imagine iterating all the characters and drawing them one-by-one using a separate sf::Text object along with getCharacterPos().
I mean that's not too bad, but maybe I am missing something.

7

Graphics / Re: Efficiency question: Sprite vs Text

« on: June 27, 2016, 10:59:59 pm »

Laurent, thanks for advice. I ran some tests, for anyone interested, here are the results.
1)

• Rendering 500 heavily overlapping text objects directly gained ~170 fps
• Rendering through sf::RenderTexture (without redrawing) gained ~380 fps.

.
2)

• Rendering 50 non-overlapping text objects directly gained ~470 fps
• Rendering through sf::RenderTexture (without redrawing) gained ~340 fps.

.
Well, the slowness of the second case with texture can be explained by the size of this texture - 800 * 800.
Anyway, bottom line: predrawing non-overlapping text is faster with plain text objects.

8

Graphics / Efficiency question: Sprite vs Text

« on: June 27, 2016, 08:22:19 pm »

So, I need to draw a lot of text on the screen - an array of sf::Text objects. This text is not going to change very often. So, I thought, why not draw all these sf::Text objects on sf::RenderTexture object and then, when the text updates, just redraw the texture? Will drawing the sf::RenderTexture through a sprite in the main window be more efficient than drawing the text in the same window?
What I think is maybe drawing text is more expensive than drawing it once on a texture and then just drawing the texture.

9

General discussions / Re: SFML Game Development book - bug in the sources?

« on: March 20, 2016, 10:03:39 am »

OK, got it, thank you. It was dumb of me not to think of that.

10

General discussions / SFML Game Development book - bug in the sources?

« on: March 20, 2016, 12:56:57 am »

So I am reading a book called SFML Game Development (and I really like it), but I think I might have found a major memory leak in the provided sources. If you go to the main repository and check this file:
https://github.com/SFML/SFML-Game-Development-Book/blob/master/10_Network/Include/Book/SceneNode.hpp
you will see that there is no virtual destructor declared. I suppose that's a bug.
Please, fix me if I am wrong.

11

Graphics / Re: Does setScale() round to highest, lowest or closest pixel?

« on: March 19, 2016, 01:54:39 am »

Oh, dear, getGlobal/LocalBounds() actually return FloatRect! I was thinking IntRects  Now all is clear.
Thank you, Laurent and Hapax!

12

Graphics / Re: Does setScale() round to highest, lowest or closest pixel?

« on: March 18, 2016, 06:17:42 pm »

Hapax, thank you for the explanation!

The float "width" is given directly to OpenGL and it decides how many pixels it wants to use depending on its current state (e.g. its view)

But does OpenGL decide what will be in sprite.getLocalBounds().width?

13

Graphics / Re: Does setScale() round to highest, lowest or closest pixel?

« on: March 17, 2016, 10:37:02 pm »

Of course it is. Why do you think it could be different? Did you have any problem?

OK, cool! Well, I did not have any problems, but here is the thought which troubled me. Suppose we take a factor that is, say, not very nice - say PI. Then, I suppose, somewhere internally, sprite width is multiplied by PI, yielding another float. Now, this float needs to be integer (since it shows amount of pixels). Would not it make sense to ceil this float value?
If we multiply not by PI, but by desiredWidth/spriteWidth instead, we will get a float which is very close to, but not exactly (since it is a float), desired width. It might be a liitle low or a little high. Well, if we use ceil and it is a little high, we get one pixel more than needed.
But apparently rounding is used, but that was the source of my confusion.

14

Graphics / Re: Does setScale() round to highest, lowest or closest pixel?

« on: March 17, 2016, 08:09:01 pm »

Hello!
Well, here is my concern. After executing this:

int desired width = 10;
float factor = desiredWidth / sprite.getLocalBounds().width;
sprite.setScale(factor, factor);

I just want to be sure that

sprite.getLocalBounds().width

will now be exactly equal to desiredWidth.

15

Graphics / Re: Does setScale() round to highest, lowest or closest pixel?

« on: March 17, 2016, 02:49:10 pm »

It's only when they are rendered that each which pixel is used to display it is decided.

That's what I wanted to ask, how will it be decided when it is rendered?