SFML 2.0 RC

[Andrei15193]

I thought you wanted the enum to start from 1 and not from 0.

No we don't care. The problem to solve was that 'A' and unhandled keys had the same code.

Oh, my bad

[binary1248]

I'm wondering is this is relevant. I mean, if I write an application and plan to distribute it, I won't rely on a specific font being present on the user's system. Instead I'll provide the font with my application for 100% safety.
So who would use this feature?

For the people who just want to see text you have the default whatever you define in SFML system font as a replacement for getDefaultFont() now. People who have an idea what font they might want on a specific system can either use the system font or specify their own. SFML should just make it easy to make use of the system fonts IF the user wants to.

[Laurent]

Then I wonder if providing a default font still makes sense.

[binary1248]

It's not a question of if there should be a default font, but where the font data comes from

[exafi]

that you changed the style of the methods?
Before was better.

GetPos ...
  now
getPos ...

-1 to this


I used Google translate XDDDD

[Tank]

I like option 2. But then it becomes similar to providing the font file directly, the only difference is that with a header it is compiled directly into the final application. But then why not go further, and provide a generic system to embed any data into the application?

The difference is that you don't have a global sf::Font object. Nobody's against global data (just make sure to declare it static const, so it won't be included X times in the binary).

I would even go one more step further and say: Why not a generic loading chain with changeable adapters for choosing which backend we want? (filesystem, archives, binary data in executable, HTTP) But that's definitely something for a later version, also the idea with generic embedded data.

However, having something like

font.load( sf::FileSystemAdapter( "foobar.ttf" ) );
font.load( sf::ZipAdapter( "foobar.ttf", "meow.zip" ) );
font.load( sf::HttpAdapter( "http://sfml-dev.org/resources/foobar.ttf" ) );
// Same for all the other load() functions, e.g. in sf::Image.
 

would be great and powerful. Maybe in SFML 4? ;-)

but as SFML has to remain compatible with pure C++03

Do you plan to drop that requirement for, let's say SFML 3?

Before was better.
...
-1 to this

-1337 for flaming.

[Laurent]

font.load( sf::FileSystemAdapter( "foobar.ttf" ) );
font.load( sf::ZipAdapter( "foobar.ttf", "meow.zip" ) );
font.load( sf::HttpAdapter( "http://sfml-dev.org/resources/foobar.ttf" ) );
// Same for all the other load() functions, e.g. in sf::Image.

Isn't it the sf::InputStream system, which is already implemented in SFML 2?

Do you plan to drop that requirement for, let's say SFML 3?

I don't know, I guess it depends when SFML 3 is released
At least I'll provide conditional support for C++11 in SFML 2 (there's an issue on the tracker for that).

[Tank]

Isn't it the sf::InputStream system, which is already implemented in SFML 2?

Indeed, I wasn't aware of it.

[jPollock]

Hi, just the case of the setString method in sf::Text class.

diff -Naur LaurentGomila-SFML-396f675.orig/include/SFML/Graphics/Text.hpp LaurentGomila-SFML-396f675/include/SFML/Graphics/Text.hpp
--- LaurentGomila-SFML-396f675.orig/include/SFML/Graphics/Text.hpp      2012-07-13 12:09:11.000000000 +0200
+++ LaurentGomila-SFML-396f675/include/SFML/Graphics/Text.hpp   2012-07-14 04:25:41.000000000 +0200
@@ -86,10 +86,10 @@
     /// automatically be constructed from standard string types.
     /// So, the following calls are all valid:
     /// \code
-    /// text.SetString("hello");
-    /// text.SetString(L"hello");
-    /// text.SetString(std::string("hello"));
-    /// text.SetString(std::wstring(L"hello"));
+    /// text.setString("hello");
+    /// text.setString(L"hello");
+    /// text.setString(std::string("hello"));
+    /// text.setString(std::wstring(L"hello"));
     /// \endcode
     /// A text's string is empty by default.
     ///
 

[eXpl0it3r]

Hi, just the case of the setString method in sf::Text class.

And? What are you trying to tell us with that? Or did I miss some talk about it?

[Hiura]

He's pointing out typos in the doc.  (S -> s)

[eXpl0it3r]

He's pointing out typos in the doc.  (S -> s)

Aha! I see!
Quite hard to spot if you don't know what to look for.

[Laurent]

Hi, just the case of the setString method in sf::Text class.

Thanks

[TheVirtualDragon]

Hi, I just wanted to ask, is SFML 2.0 rc stable enough for use? As in, my application wont have too many problems?
Also, how many changes will there be between SFML 2.0 and 2.0rc? I am wondering because I don't want to have many changes when SFML 2.0 comes out and I link to it.

[eXpl0it3r]

SFML 2.0rc is quite stable. The main part of the API is frozen and changes to the API will only happen if there's a really, really good reason for. So you can consider it as stable. The most recent bigger change was the removal of the default font. If you're using the SFML 2rc binaries just don't use the default font and you won't have to change a thing when SFML 2 finally gets released. (If that ever happens )

If you want to see what the changes are between the RC and the current state you can take a look at the commit history up to the 2.0-rc tag.