SFML 2.0 Releases

[Wismi]

I worked with v 1.6 for a while, and was relatively happy with it.  However, I frequently have come across various issues that required a v2.0 update.  This appears to be only available in source form.  When I build, I have the following issue:

In VS2005, the freetype.lib included is unuseable for debug builds (sfml-graphics...).  I have to substitute the file from 1.6 to get it to build.  That seems to work.

However, I now have issues with libsndfile-1.dll when I shutdown.  I am using the version from the 2.0 build and it fails to shutdown without errors.  However, the version from 1.6 does not give the error, but is incapable of opening my .ogg file.

I guess I have two questions:
1) Since 2.0 isn't released, I can't determine if any version of it is stable, or "centered" for release.  When will an official version of SFML 2.0 be released?

2) Is there a .ogg file format rate/sample size I should be always using?

[Laurent]

In VS2005, the freetype.lib included is unuseable for debug builds (sfml-graphics...). I have to substitute the file from 1.6 to get it to build. That seems to work.

Really? I've never had any issue with this. What errors do you have?

However, I now have issues with libsndfile-1.dll when I shutdown. I am using the version from the 2.0 build and it fails to shutdown without errors. However, the version from 1.6 does not give the error, but is incapable of opening my .ogg file.

Again, which errors?

1) Since 2.0 isn't released, I can't determine if any version of it is stable, or "centered" for release. When will an official version of SFML 2.0 be released?

Dunno. Unfortunately, I can't spend as much time as I want on it.

2) Is there a .ogg file format rate/sample size I should be always using?

No, why do you ask this question?

I have one question for you: are you sure that you don't somehow mix 1.6 and 2.0? These external libs errors that you're describing seem to be really weird. Do you link to dyanmic or static SFML libs? Have you tried the other way?

[Wismi]

Really? I've never had any issue with this. What errors do you have?

When I try to create a debug build with the included 2.0 version of freetype.lib, I get a linker error message stating that the debug information is corrupt.  This does not happen on a release build, or if I use the 1.6 supplied version of this file.  My best guess is that the freetype.lib file was built with VS 2008, and my VS 2005 cannot read the debug information.  Using the 1.6 supplied version does not seem to create any problem.

Again, which errors?

Whenever this file is loaded on behalf of music, I get errors around or about mutex(.h?).  I use sounds, and that does not seem to present problems for .wav files (very small).  When I try to use an .ogg file for music, I am told that it is a valid file type, but an invalid format.  No music of course.  The access violation occurs when the shutdown happens.  Probably the original exception left something around that did not get cleaned up when exiting.  If I can get it to play a music file without errors, the rest will probably take care of itself.

No, why do you ask this question?

Reasons listed above.

I have one question for you: are you sure that you don't somehow mix 1.6 and 2.0? These external libs errors that you're describing seem to be really weird. Do you link to dyanmic or static SFML libs? Have you tried the other way?

I updated the paths, and believe I have them living separately well enough.  Except freetype.lib when I rebuilt the graphics dll for debug mode.  I wanted to avoid static libs and prefer DLLs in my local directory, since in theory I would not update them as often to anyone testing the application.

[Tronic]

SFML2 seems somewhat dead with no updates on news. Perhaps it would be a good time to go for release early, fix after, to get things rolling again? Trying to make too big changes and then releasing a "perfect new version" is not healthy.

[Laurent]

The problem is that once it is released, backward-incompatible API changes won't be allowed anymore, and will have to be postponed to... SFML 3.
So I must complete them; and I've already postponed other changes (that don't break the API) to SFML 2.x.

[Tronic]

You know, Khronos tried that same thing with OpenGL 3.0 and failed. Instead, they finally had to release because it wasn't going anywhere. Since then it has been perfected in the subsequent releases even though that has meant some API borkage via deprecated and removed features in 3.1 and other further releases.

Maybe most importantly you really find out how the API should work when the library is in widespread use and you get user feedback. Unfortunately that will only happen with an actual release.

[Nexus]

I don't think it's a good idea to release SFML 2 as soon as possible only for the sake of being released. A new SFML version is expected to be more or less stable, no one wants to change everything in 2.1 again. I mean, those people interested in the new things can already use the SVN version (like I do).

By the way: I don't think the comparison with OpenGL 3.0 is a very good one. The problems were mainly that the Khronos group promised more than they kept and that they didn't inform the community about the API progress. Both points do not apply to SFML 2.

[Wismi]

Maybe a fair compromise is to take a version of 2.0 that lasted a while and had few issues and call it 1.7, 1.8 or 1.9?

[Groogy]

Probably not since 2.0 got changes to the interface of SFML, among other things. Though I suspect that's the main reason.