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

Author Topic: Promote SFML 2 instead of SFML 1.6  (Read 16008 times)

0 Members and 1 Guest are viewing this topic.

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6275
  • Thor Developer
    • View Profile
    • Bromeon
Promote SFML 2 instead of SFML 1.6
« on: January 16, 2013, 10:11:36 am »
Hi,

Almost every newcomer begins to use SFML 1.6, because it is declared as "current version" on the website, and they get the impression that SFML 2 is unfinished or beta, although much more mature than 1.6. Guys like eXpl0it3r have to argument in every second post why SFML 2 is better and should be used instead. I actually agree with him, and also often advise people to switch.

The website should really be changed accordingly. I know you will do it anyway when SFML 2 is released, but since we don't know exactly when this is going to happen, it may be better to promote SFML 2 RC already. We also avoid that people who begin now with SFML have to port everything as soon as they have learned the basics.

I am also aware that SFML 2 RC isn't complete regarding the tutorials, yet this should be outweighed by SFML 2's advantages. Using the SFML 2 doc, examples and 1.6 tutorials, most parts can still be learned reasonably. Otherwise, there is still the forum to ask.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

FRex

  • Hero Member
  • *****
  • Posts: 1839
  • Not doing gamedev/using SFML lately
    • View Profile
    • Email
Re: Promote SFML 2 instead of SFML 1.6
« Reply #1 on: January 16, 2013, 10:25:34 am »
+1 to this, I'm really tired of idiots who have problems writing a hello world in whatever library for graphics and at the same time say to people with couple thousands of posts that they're wrong.
http://en.sfml-dev.org/forums/index.php?topic=9720.msg66733#msg66733
This question was actually caused by the fact I was arguing with some complete moron who said that 1.6 is much betterthan 2.0(he made it sound like if 2.0 is crashing randomly) because 'Laurent said so but I forgot where and when' few months back so I wanted a post with Laurent's answer to use whenever I ran into another one of these morons.
« Last Edit: January 16, 2013, 10:38:16 am by FRex »
I'm not using SFML nor doing any gamedev lately.

Foaly

  • Sr. Member
  • ****
  • Posts: 453
    • View Profile
Re: Promote SFML 2 instead of SFML 1.6
« Reply #2 on: January 16, 2013, 10:32:14 am »
+1! Even though SFML 2.0 is not released yet, it beats SFML 1.6 by far. If you're about to start coding with SFML there is absolutely no reason to use 1.6

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1485
    • View Profile
    • Blog
    • Email
Re: Promote SFML 2 instead of SFML 1.6
« Reply #3 on: January 16, 2013, 11:37:39 am »
I second what Nexus said. There's no reason to declare 1.6 being stable anymore – because it isn't. ;) I'm aware that there are already API changes from 2.0 RC to HEAD, but that's not a problem of the "RC", it's a problem of the versioning.

Personally I hadn't release an RC, but 2.0 instead. It's much easier to throw changes into a specific version, and if users decide to upgrade, they know that they might run into compatibility issues. That way you could have just released 2.0, and some more API changes/features in 2.1, and so on.

I'd generally suggest to lower the release cycle time. It reduces the workload per version (less features added), including writing documentation. The current situation is not really feasible for development: We have 1.6, greatly outdated (for several years) and SFML 2.0 RC, which is not declared as being stable. As a new user, to be honest, I'd go with 1.6 too, just because it's "stable".

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10193
    • View Profile
    • development blog
    • Email
Re: Promote SFML 2 instead of SFML 1.6
« Reply #4 on: January 16, 2013, 11:52:00 am »
Guys like eXpl0it3r have to argument in every second post why SFML 2 is better and should be used instead.
+1
+1!
I second what Nexus said. There's no reason to declare 1.6 being stable anymore – because it isn't. ;)
I've nothing more to add other than: I strongly advise you against the use of SFML 1.6, because it's around 2.5 years old, has quite a few ugly bugs and lacks a lot of nice features (e.g. sf::VertexArray, sf::RenderTexture, ...)... ;D
« Last Edit: January 20, 2013, 12:55:38 pm by eXpl0it3r »
Official FAQ: https://www.sfml-dev.org/faq.php
Nightly Builds: https://www.nightlybuilds.ch/
——————————————————————
Dev Blog: https://dev.my-gate.net/
Thor: http://www.bromeon.ch/libraries/thor/

cooldog99

  • Jr. Member
  • **
  • Posts: 95
    • View Profile
    • Perilous Game Studios
Re: Promote SFML 2 instead of SFML 1.6
« Reply #5 on: January 16, 2013, 12:50:05 pm »
For what it's worth, I also second this.
+1!

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6275
  • Thor Developer
    • View Profile
    • Bromeon
Re: Promote SFML 2 instead of SFML 1.6
« Reply #6 on: January 16, 2013, 01:38:01 pm »
Personally I hadn't release an RC, but 2.0 instead.
I think Laurent intends not to break the API once SFML 2.0 is released. The RC says: The final version will be very similar, but there might be minor changes.

I'd generally suggest to lower the release cycle time. It reduces the workload per version (less features added), including writing documentation. The current situation is not really feasible for development: We have 1.6, greatly outdated (for several years) and SFML 2.0 RC, which is not declared as being stable.
I totally agree.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1485
    • View Profile
    • Blog
    • Email
Re: Promote SFML 2 instead of SFML 1.6
« Reply #7 on: January 16, 2013, 01:57:44 pm »
I seem to be one of the few people who don't have problems with API changes at all. I even think they are required if you want to keep your code clean.

I see it like this: When I'm using 2.0, and 2.1 introduces the "ThreeDeeMagic" feature which I'd like to use, then I have to adjust my code to do so. When I'm using something that's already available in 2.0 and is changed in 2.1 (API), then I need to adjust my code – otherwise I probably don't *need* 2.1. Looks quite similar to me.

Of course it's always nice to be able to upgrade to a newer version without any extra work. But if there are good reasons (more stable API, features, code design, ...), I'm perfectly fine with compiler errors after trying to upgrade without adjusting my code at all. :)

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6275
  • Thor Developer
    • View Profile
    • Bromeon
Re: Promote SFML 2 instead of SFML 1.6
« Reply #8 on: January 16, 2013, 03:40:39 pm »
But if there are good reasons (more stable API, features, code design, ...), I'm perfectly fine with compiler errors after trying to upgrade without adjusting my code at all. :)
The really annoying changes are those who let old code compile and introduce silent bugs. The change from float seconds to sf::Uint32 milliseconds was such an example, the sf::Rect modification another one (when using the constructor). I remember fixing loads of bugs because of it in Zloxx II ;)

I still agree with you, as long as the changes are justified because of a better design or new feature, I can mostly accept them. Backward compatibility is a good thing on one side, but on the other it sometimes blocks progress and makes things terribly ugly. But we also have to consider that SFML is being more and more widely used, and some people (or even small companies) consider a stable API across multiple minor versions crucial. As the maintainer of two big projects, you probably aren't unhappy about fewer changes, either :)
« Last Edit: January 16, 2013, 03:47:41 pm by Nexus »
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1404
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: Promote SFML 2 instead of SFML 1.6
« Reply #9 on: January 16, 2013, 07:23:35 pm »
Guys like eXpl0it3r have to argument in every second post why SFML 2 is better and should be used instead.
Or he could just point at the (incomplete) FAQ which manages to get the point over somehow instead of writing the same semi-wall-of-text in every second thread ::).

I'd generally suggest to lower the release cycle time. It reduces the workload per version (less features added), including writing documentation. The current situation is not really feasible for development: We have 1.6, greatly outdated (for several years) and SFML 2.0 RC, which is not declared as being stable. As a new user, to be honest, I'd go with 1.6 too, just because it's "stable".
+1337
Look at the new versioning method of SFGUI (Tank's idea btw) it shows people that progress is being made but it doesn't promise them crap regarding stability :P. Holding up a complete rewrite in 1 version number over the course of years isn't a good idea. If you had a truck-load of coffee and could do it in a night, maybe you should go for it. But stopping support for a "stable" version for so long to work on something that you brand as unstable doesn't leave many people much choice but to use the "stable" version (which ironically is less stable than the unstable one) because they don't understand what benefits using 2.0 bring.

Actually if you consider the word "stable" implying that software is actively maintained, improved, bugs squished, etc. then you wouldn't be allowed to call 1.6 stable any more because let's face it, it's less stable than something I write for SFGUI in less than a day :D if you consider that it doesn't run on many very popular GPUs, crashes in way too many scenarios, etc.

Development does not always imply instability, especially not if it is on a feature by feature basis and certain features can be considered "done" independently of the others. This is what minor version numbers are for IMHO.

P.S.
and 2.1 introduces the "ThreeDeeMagic" feature which I'd like to use
What? Why didn't you tell me you wanted 3D magic? I will see what I can do. Not signing any contracts though :P
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

masskiller

  • Sr. Member
  • ****
  • Posts: 284
  • Pointers to Functions rock!
    • MSN Messenger - kyogre_jb@hotmail.com
    • View Profile
    • Email
Re: Promote SFML 2 instead of SFML 1.6
« Reply #10 on: January 16, 2013, 08:16:58 pm »
Quote
Or he could just point at the (incomplete) FAQ which manages to get the point over somehow instead of writing the same semi-wall-of-text in every second thread ::).

That will only save a little typing. It has become too much of a common thing for help requests to come only to show people that they should change to 2.0 due to the fact that reporting a bug is useless for that version and that most decent help (if not all) you can get in these forums is related to 2.0 and not 1.6 since it's the most used by any user from intermediate to advanced unless there is a strict reason. The change should be done, even if the final version of 2.0 doesn't come anytime soon.
Programmer, Artist, Composer and Storyline/Script Writer of "Origin of Magic". If all goes well this could turn into a commercial project!

Finally back into the programming world!

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Promote SFML 2 instead of SFML 1.6
« Reply #11 on: January 17, 2013, 08:57:06 am »
Promote SFML 2
I know... but not doing it forces me to work hard on the final release (which is really close) ;)

Short release cycles
Definitely! You can expect SFML 2.1 to be released a few months after 2.0, and so on.

Release SFML 2 sooner
A lot of stuff had to be rewritten (internal code, public API, tutorials, documentation, website, ...) and I really wanted a clean and stable base for this new 2.x branch. I want to stop breaking API compatibility with minor releases, so that SFML, with its 2nd edition, can finally be used as a stable library rather than something "unfinished".
Laurent Gomila - SFML developer

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1485
    • View Profile
    • Blog
    • Email
Re: Promote SFML 2 instead of SFML 1.6
« Reply #12 on: January 17, 2013, 10:57:42 am »
Quote from: binary1248
What? Why didn't you tell me you wanted 3D magic? I will see what I can do. Not signing any contracts though
I want all kind of magic!

Quote from: Laurent
Definitely! You can expect SFML 2.1 to be released a few months after 2.0, and so on.
Please don't forget about the revision part of a version. Fixed Bug > Feature. ;)

Quote from: Nexus
The change from float seconds to sf::Uint32 milliseconds
Didn't your compiler warn you?

Quote from: Nexus
But we also have to consider that SFML is being more and more widely used, and some people (or even small companies) consider a stable API across multiple minor versions crucial.
Yes, and an API that doesn't change means 1) it's really good or 2) the developer is too afraid changing it. ;) I think as long as upcoming changes are communicated good enough, one shouldn't stop implementing them.

Quote from: Nexus
As the maintainer of two big projects, you probably aren't unhappy about fewer changes, either
Actually I really don't care that much. I add, change and remove code all the time anyway. ;) And I guess we're not talking about changes that require rewrites of bigger parts in a project (the changes from 1.6->2.0 are massive, and big 1.6 projects might need a fair amount of time and effort to be ported; however, this is a major version change). If new versions are published in shorter intervals, then there's probably no need to increment the major version counter.

I guess we kinda agree to each other except on details. For SFGUI it would be nice to see the light of SFML 2.0, as it means one less dependency to be tracked for changes. :)

NPS

  • Newbie
  • *
  • Posts: 31
    • View Profile
Re: Promote SFML 2 instead of SFML 1.6
« Reply #13 on: January 17, 2013, 02:07:48 pm »
One huge argument against. I don't know about the documentation but the tutorials are only like started and they miss much (most?) of the functionalities. And that's unacceptable - reading tutorials for previous version, then looking in the documentation of both the current and the previous versions in search of changes, and finally posting on forums when one gets lost in all this IS NOT THE WAY TO GO. And that's what someone's suggesting. I love SFML not only because it works and does all the stuff I need but also because learning it is so fast, intuitive and simple! But that's not the case with the 2.0 version right now and until it is - don't promote 2.0.

masskiller

  • Sr. Member
  • ****
  • Posts: 284
  • Pointers to Functions rock!
    • MSN Messenger - kyogre_jb@hotmail.com
    • View Profile
    • Email
Re: Promote SFML 2 instead of SFML 1.6
« Reply #14 on: January 17, 2013, 02:28:37 pm »
Quote
One huge argument against. I don't know about the documentation but the tutorials are only like started and they miss much (most?) of the functionalities. And that's unacceptable - reading tutorials for previous version, then looking in the documentation of both the current and the previous versions in search of changes, and finally posting on forums when one gets lost in all this IS NOT THE WAY TO GO. And that's what someone's suggesting. I love SFML not only because it works and does all the stuff I need but also because learning it is so fast, intuitive and simple! But that's not the case with the 2.0 version right now and until it is - don't promote 2.0.

You can skip the step of looking at the 1.6 doc, when I started I found it useless and still learned how to use the library without much hassle, porting the code between versions isn't hard and unless you want to go and use low level API right away you won't really suffer.

The Graphics API was rewritten (and for the greater good) and that's granted, however other than the adding of sf::Texture and the need to keep it alive you won't really notice the other changes unless you start using the new features right away.

Quote
I know... but not doing it forces me to work hard on the final release (which is really close) ;)

This I would consider the main reason not to, if it means getting the final version sooner then I don't care about posting the same thing over and over in the help forums for a few months.

Programmer, Artist, Composer and Storyline/Script Writer of "Origin of Magic". If all goes well this could turn into a commercial project!

Finally back into the programming world!