SFML 3 - What is your vision?

[dabbertorres]

There's been a few times for myself that having the sf::Text hold a reference to a string rather than a value would've been nice. I'd be a fan of the change if it was done.

Was there a design decision as to why it holds a value? I mean, most of the API holds references rather than values.

[ChronicRat]

There's been a few times for myself that having the sf::Text hold a reference to a string rather than a value would've been nice. I'd be a fan of the change if it was done.

Was there a design decision as to why it holds a value? I mean, most of the API holds references rather than values.

How good it will be in multithreaded app?

[zsbzsb]

There's been a few times for myself that having the sf::Text hold a reference to a string rather than a value would've been nice.

Until you realize that there would be not any clean solution for the text object to know if the reference it points at has changed its string and internal states need to be updated.

[Oldie]

Until you realize that there would be not any clean solution for the text object to know if the reference it points at has changed its string and internal states need to be updated.

That is what I thought, more or less. Until very recently I had a utility struct acting as a wrapper on top of sf::Text, which also held a container of sf::String*. The idea was to give the needed strings to the Text instance once, and then forget about them. But even this way, whenever the language changed, I had to do myOwnText::update(), with no argument, so as to apply sf::Text::setString() internally.
I got rid of myOwnText today, and now only rely on sf::Text again and store the needed strings case by case.

[zsbzsb]

That is what I thought, more or less. Until very recently I had a utility struct acting as a wrapper on top of sf::Text, which also held a container of sf::String*. The idea was to give the needed strings to the Text instance once, and then forget about them. But even this way, whenever the language changed, I had to do myOwnText::update(), with no argument, so as to apply sf::Text::setString() internally.

My point exactly  either way a function needs to be called on the sf::Text object. 

[dabbertorres]

Heh, well that was painfully obvious.

[heishe]

Haven't logged in in a long time, but this is important to me since I love SFML as a library, but meta-topics keep me and my team from using it at work.

What's an absolute must is cross platform support that also covers mobile platforms, namely android, ios, and windows phone. Would be helpful if you went a way similar to Cocos2D, which now includes a cross-platform project management and build tool, but I guess that's never been the focus of SFML so I don't suspect you will look into it.

[Nexus]

Was there a design decision as to why it holds a value? I mean, most of the API holds references rather than values.

In general, value semantics are more transparent, less surprising and easier to use than reference semantics. For example, sf::RenderWindow::setView() was changed to store a copy because of that.

I wouldn't say most of the API holds references, it's only a small part. Except for places where a copy is clearly inappropriate (mostly resources), setters store the passed value in the class.

[StDH]

- C++11: std::to_string ...
- Network: nat hole punching, define packets ttl, timestamp
- Graphics: motion blur shader, shake screen
- Global: "inline" for short functions [like getPosition(), getRotation() ...etc]
- System: add precise clock: std::chrono

[binary1248]

SDH, I can't tell what you really meant with all the things you listed.

- C++11: std::to_string ...

So, why can't you just use std::to_string then?

- Network: nat hole punching, define packets ttl, timestamp

NAT hole punching isn't something you can just "enable" between 2 parties, it always consists of at least one party that doesn't require hole punching e.g. an internet server and the parties that do. So in case the 2 parties who are both trying to communicate behind each other are behind NAT gateways, you will need a publicly accessible server somewhere in the internet. This is really not a feature any more, but rather a concrete use case.

I don't see any reason to be able to define a packets TTL. TTL is meant to prevent packets from travelling the internet forever. Besides that, the only reason to be able to manually set it is for diagnostic purposes e.g. traceroute. In normal cases, you can rely on the operating system setting the TTL value properly.

I also don't understand what you mean by "timestamp". If you want to add a timestamp to your packets, then you can already do so. What does this have to do with being a new feature?

- Graphics: motion blur shader, shake screen

These are post-processing effects which are already possible with sf::Shader.

- Global: "inline" for short functions [like getPosition(), getRotation() ...etc]

If you enable optimizations, you will find that more often than not, the compiler is smart enough to inline calls where they make sense. The opposite is also true, they don't inline where it doesn't make sense, even if the function is marked inline by the programmer. In the end it is only a hint, and a good optimizer shouldn't need that many hints to produce a program that runs fast, even without explicit inlines.

- System: add precise clock: std::chrono

So, do you want SFML to replicate std::chrono? Is there a reason you would rather use SFML's sf::Clock rather than std::chrono? Currently, SFML's clock might even have a higher resolution than std::chrono's high_resolution_clock, so I don't understand what exactly you are requesting.

[StDH]

i dont want to replace it with chrono just add something like sf::PreciseClock

[binary1248]

i dont want to replace it with chrono just add something like sf::PreciseClock

But sf::Clock already has maximum precision.

[StDH]

i am sorry......
now i see: asMicroseconds

[magneonx]

I wish there would be a class called Camera. That could be very handy... Panning, Viewing, Zooming, etc. Although I know you can do it on sf::View, but I think its a cool idea to add Camera.

Also, SFML should also go 3D. Maybe on SFML4 or 5?

[Nexus]

I wish there would be a class called Camera. That could be very handy... Panning, Viewing, Zooming, etc. Although I know you can do it on sf::View, but I think its a cool idea to add Camera.

So you want to add a second class that does the same as sf::View but with another name?

Or what functionality is missing in sf::View?