Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: New SVN Version  (Read 10066 times)

0 Members and 1 Guest are viewing this topic.

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
New SVN Version
« on: June 08, 2008, 07:30:02 pm »
Hi,
Today I updated from SFML 1.2 to the new SVN version.
I see, there are many changes. Some new features are quite nice, for example the sf::Shape class. But some I can't really understand.

For example:
Code: [Select]
sf::Sprite::GetLeft();        // old
sf::Sprite::GetPosition().x;  // new

sf::View::GetWidth();    // old
sf::View::GetSize().y;   // new


The fact of typing more is not even the worst. The names of the functions seem to be quite random, sometimes there is still GetWidth(), and sometimes that GetSize().x. What's the point of making the names so inconsistent? Do you just want to have an own Getter for specific properties (position, rotation, size, scale)?

And the other thing is, everything has to be an own class now. For me, there's currently too much OOP in SFML. For example, you can't just write a normal sf::String constructor. Instead, the font has to be an own class (a string doesn't seem to be sufficient) which unfortunately doesn't own any specific constructors. The sf::WindowSettings struct is another example.

Up to now, I have been really impressed by SFML, but now I am a little bit deceived. Couldn't there be a possibility to at least add the old GetX() and GetWidth() again? And why did you change "Left" to "X" and "Top" to "Y"? Before it was much clearer.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
New SVN Version
« Reply #1 on: June 08, 2008, 07:50:04 pm »
The names are not random nor inconsistent, they perfectly reflect what the changes made to the functions. However, if you can spot an inconsistency in the new functions, I'll be glad to see it :)

I don't think there's too much OOP. The string and font stuff was a huge inconsistency  : fonts had their own internal manager, whereas all other resources don't. Now all the resources (I mean, stuff which can be loaded from a file) behave exactly the same : images, fonts and sound buffers. Replacing the internal manager with a new class also adds much more flexibility, as sf::Font can now expose more parameters and be extended in the future if necessary.

Same for sf::WindowSettings, it justs gathers all the parameters which can be useful at creation time for the OpenGL context, instead of having creation functions which have hundreds of parameters. Much more powerful and maintainable.

Quote
Up to now, I have been really impressed by SFML, but now I am a little bit deceived

You shouldn't stop on such considerations, all the modifications made in version 1.3 are really meaningful and will make SFML more powerful and flexible. I always put special efforts in keeping a consistent and flexible public interface, trust me ;)

Quote
Couldn't there be a possibility to at least add the old GetX() and GetWidth() again?

GetX() wouldn't mean anything in the new version (see below), and GetWidth() is exactly the same as GetSize().x (if you don't mind writing 1 more character ;)).
One important addition for 1.3 is 2D and 3D vectors, to be able to pack attributes with X, Y and Z coordinates in one variable. This makes the code much cleaner (1 function per attribute instead of 2 or 3). Then I can't keep the old names (width and height becomes size).

Quote
And why did you change "Left" to "X" and "Top" to "Y"? Before it was much clearer.

Because the origin of a drawable is no longer at the top-left corner, you can now put it where you want (center, right-bottom corner, ...). It would be a non-sense to keep Left and Top.
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
New SVN Version
« Reply #2 on: June 08, 2008, 08:42:43 pm »
Ah ok, from this point of view I didn't see it ;)
I couldn't reproduce some of the changes you've made, so I had doubts. You don't have to be scared, I won't stop using SFML, it's a very good library. :) Just some little thing don't please me too much, but I think I will get used to them...

And until now, I only experienced the (for me) bad part, but I believe that new improvements like vector classes and consistent resource system will help me in future, too ;)

Quote
Quote
And why did you change "Left" to "X" and "Top" to "Y"? Before it was much clearer.

Because the origin of a drawable is no longer at the top-left corner, you can now put it where you want (center, right-bottom corner, ...). It would be a non-sense to keep Left and Top.

Okay, but... what does "origin" in this context mean then? And you said that the function GetX() wouldn't mean anything in the new version, what do you exactly mean? Just to replace it by GetPosition().x? There is also a SetX(), will it soon be useless (only because of the X/Left discussion)?

And about the sf::Font... Could you make one specific constructor taking a std::string parameter for the file name? Or did you design this class to load a font file after construction?
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
New SVN Version
« Reply #3 on: June 08, 2008, 09:12:44 pm »
Quote
You don't have to be scared, I won't stop using SFML, it's a very good library

I don't mind if someone doesn't like SFML, my goal is not to dominate the world with it ;) It would even be better for me, as there would be a discussion about bad points in SFML and how I could improve it :)

Quote
Okay, but... what does "origin" in this context mean then?

The center of translation, rotation and scaling.

Quote
And you said that the function GetX() wouldn't mean anything in the new version

Sorry, I wrote "GetX" but I actually had "GetLeft()" in mind :oops:
So forget what I said about it, it's just the same reason as GetWidth().

Quote
And about the sf::Font... Could you make one specific constructor taking a std::string parameter for the file name? Or did you design this class to load a font file after construction?

As I don't use exceptions, there's no way to notify an error on loading failure. That's why you have to use the LoadFromFile function, which returns a boolean. And yes, this is all on purpose ;)
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
New SVN Version
« Reply #4 on: June 08, 2008, 09:35:00 pm »
Quote from: "Laurent"
Quote
Okay, but... what does "origin" in this context mean then?

The center of translation, rotation and scaling.

So by using SetX(), SetY() or SetPosition() I place this center and by GetPosition() I get its coordinates? Sorry, I just want to feel certain ;)

Quote from: "Laurent"
Quote
And about the sf::Font... Could you make one specific constructor taking a std::string parameter for the file name? Or did you design this class to load a font file after construction?

As I don't use exceptions, there's no way to notify an error on loading failure. That's why you have to use the LoadFromFile function, which returns a boolean. And yes, this is all on purpose ;)

Okay, then it's similar to the sf::Image class. I am just not used to classes without specific ctors :D

And, another question: Where is the log file where I can see what changed in SVN since 1.2? Or is there something like a doc for the newest functions?
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
New SVN Version
« Reply #5 on: June 08, 2008, 10:18:47 pm »
Quote
So by using SetX(), SetY() or SetPosition() I place this center and by GetPosition() I get its coordinates? Sorry, I just want to feel certain

No ;)
To change the center you have to use the new function SetCenter (coordinates must be relative to the top-left corner, which is the default center). Then, when you use SetPosition you move this center (and of course the sprite which is around it :D).
Regarding rotation and scaling, the center is the point that won't move (the sprite will rotate / stretch around it).

Quote
Where is the log file where I can see what changed in SVN since 1.2?

You have the roadmap on the website for a summary, and the SVN log for more details (see with your SVN client -- "show log" with TortoiseSVN).

Quote
Or is there something like a doc for the newest functions?

From the next release on, the tutorials for SVN versions will be available online, as well as tutorials for old versions. Maybe the doxygen documentation too.
Laurent Gomila - SFML developer

SirJulio

  • Full Member
  • ***
  • Posts: 241
    • View Profile
New SVN Version
« Reply #6 on: June 08, 2008, 10:19:56 pm »
Hi,

maybe you could see the done category in roadmap page. For docs, Hiura on the french forum keep an up-to-date doc, here.

dabo

  • Sr. Member
  • ****
  • Posts: 260
    • View Profile
    • http://www.dabostudios.net
New SVN Version
« Reply #7 on: June 08, 2008, 11:56:19 pm »
While we are discussing the new font-class, I have a question.

I have a feeling I might be using it wrong. If I want to use the same font but with different font-sizes do I need to load the font multiple times? For example:

Code: [Select]
if(!FontSmall.LoadFromFile("./gamedata/gfx/FreeSansBold.ttf", 8))
exit(EXIT_FAILURE);

if(!FontMedium.LoadFromFile("./gamedata/gfx/FreeSansBold.ttf", 10))
exit(EXIT_FAILURE);

if(!FontBig.LoadFromFile("./gamedata/gfx/FreeSansBold.ttf", 12))
exit(EXIT_FAILURE);


Because if I don't use the same char-size and string-size the text is not drawn very nice, like below (not a complete code but you get the idea):

Code: [Select]
if(!Font.LoadFromFile("./gamedata/gfx/FreeSansBold.ttf", 10))
exit(EXIT_FAILURE);

sf::String Text;
Text.SetColor(sf::Color(0, 0, 0));
Text.SetFont(Font);
Text.SetSize(8.f);
Text.SetText("Hello World");
Text.SetSize(10.f);
Text.SetText("Hello World");
Text.SetSize(12.f);
Text.SetText("Hello World");

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
New SVN Version
« Reply #8 on: June 09, 2008, 09:11:08 am »
Quote
I have a feeling I might be using it wrong. If I want to use the same font but with different font-sizes do I need to load the font multiple times?

Yes you have to load it multiple times. This is because internally the font is rasterized and stored as an image. A different character size will produce a new image.

Quote
Because if I don't use the same char-size and string-size the text is not drawn very nice

You'll never be able to get a perfect display of text if you scale your string or your font, and I can't help much about that. Look at modern games (eg. Half-Life 2) : they have to use specific techniques using pixel shaders to get a perfect text rendering at any scale.
However, in most cases the text will be nice enough, you don't really have to load the font so many times.
Laurent Gomila - SFML developer

dabo

  • Sr. Member
  • ****
  • Posts: 260
    • View Profile
    • http://www.dabostudios.net
New SVN Version
« Reply #9 on: June 09, 2008, 02:16:55 pm »
Using the setup above (loading multiple times) the text is drawn nicely, I just wasn't sure I was using the font-class correctly.

Avency

  • Full Member
  • ***
  • Posts: 113
    • View Profile
New SVN Version
« Reply #10 on: June 09, 2008, 05:02:34 pm »
Quote from: "Laurent"
As I don't use exceptions, there's no way to notify an error on loading failure. That's why you have to use the LoadFromFile function, which returns a boolean. And yes, this is all on purpose ;)

What are your reasons for not using exceptions?

Instead of writing (just to pick up the above code):

Code: [Select]

if(!FontSmall.LoadFromFile("./gamedata/gfx/FreeSansBold.ttf", 8))
      exit(EXIT_FAILURE);

if(!FontMedium.LoadFromFile("./gamedata/gfx/FreeSansBold.ttf", 10))
      exit(EXIT_FAILURE);

if(!FontBig.LoadFromFile("./gamedata/gfx/FreeSansBold.ttf", 12))
      exit(EXIT_FAILURE);


You could write:

Code: [Select]

try
{
     FontSmall.LoadFromFile("./gamedata/gfx/FreeSansBold.ttf", 8);
     FontMedium.LoadFromFile("./gamedata/gfx/FreeSansBold.ttf", 10);
     FontBig.LoadFromFile("./gamedata/gfx/FreeSansBold.ttf", 12);
}
catch (LoadingExeption& Ex)
{
     Ex.WriteErrorToLog(Log);
     return EXIT_FAILURE;
}


This way you could also provide constructors taking the filename (or something like sf::File, ever thought about that?) as a parameter directly.

It simplifies things a lot. (I was actually going to post this in feature requests.)

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
New SVN Version
« Reply #11 on: June 10, 2008, 04:08:08 pm »
Quote
What are your reasons for not using exceptions?

Actually there's no strong reason not to use them, it's more a design choice.
The thing with an exception is that such an error is fatal and breaks the code flow. In SFML, I always try to treat errors as not fatal; instead, when an error happens I prefer leaving the objects in a valid but incorrect state (eg. a white sprite when loading an image failed), and throw a message on the standard error output. Moreover, I think this way of handling errors is much easier for beginners ; it's also more convenient when interfacing with C and other languages.
Laurent Gomila - SFML developer

quasius

  • Full Member
  • ***
  • Posts: 166
    • View Profile
New SVN Version
« Reply #12 on: June 10, 2008, 05:20:40 pm »
Quote from: "Laurent"
Quote
What are your reasons for not using exceptions?

Actually there's no strong reason not to use them, it's more a design choice.
The thing with an exception is that such an error is fatal and breaks the code flow. In SFML, I always try to treat errors as not fatal; instead, when an error happens I prefer leaving the objects in a valid but incorrect state (eg. a white sprite when loading an image failed), and throw a message on the standard error output. Moreover, I think this way of handling errors is much easier for beginners ; it's also more convenient when interfacing with C and other languages.


Agree.

Avency

  • Full Member
  • ***
  • Posts: 113
    • View Profile
New SVN Version
« Reply #13 on: June 10, 2008, 07:27:47 pm »
Thanks for your reply.
I definitely agree on the last argument, it was just that I'm a big fan of exceptions  :).
IMHO exceptions do not break the code flow, they however require other programming techniques.

pamaury

  • Newbie
  • *
  • Posts: 31
    • View Profile
New SVN Version
« Reply #14 on: June 10, 2008, 07:42:53 pm »
Quote
You'll never be able to get a perfect display of text if you scale your string or your font, and I can't help much about that. Look at modern games (eg. Half-Life 2) : they have to use specific techniques using pixel shaders to get a perfect text rendering at any scale.
However, in most cases the text will be nice enough, you don't really have to load the font so many times.


There is one solution however when using TrueType font because there are internally stored as Bezier curves so using a predefined step to approximate them and storing the result in a display list allows to render characters at different scales without recreating them(given a small enougth approximation step). Of course this has the disadvante of being specific to TT fonts and to require more work at the loading times but the result is more beautiful(I believe). I don't know if it's more or less efficient than using textures.