Future release of SFML 2.2 (feedback needed)

[Laurent]

Hi

I'd like to announce the future release of SFML 2.2. I don't have a precise schedule, so don't ask "when"; all I can say is that it will be soon.

My plans are to integrate the ios/android branch, even if not 100% stable. As long as the public API is stable, it doesn't hurt to include these ports as a "technology preview" in SFML 2.2.

I'll also include the additional blending modes branch after more testing.

So basically I open this thread to get more feedback from you, users. What do you think should be integrated into SFML 2.2? What critical bugs should be fixed? Keep in mind that "soon" means that we'll work on important / critical tasks only, don't start to suggest tons of new features here

[Oldie]

I guess any bug or regression that does not lead to a change in the current API should be fixed, whether it is critical or minor. That goes for any release of any application, actually.

My 2 cents.

[Marukyu]

Hayo! I'm looking forward to the release of 2.2! It's going to be interesting to play around with the mobile ports.

One of the oldest active issues on the tracker, and in my opinion the greatest shortcoming of SFML, is the lack of proper handling for international keyboard layouts. Nearly every special key on my QWERTZ keyboard is reported as "sf::Keyboard::Unknown", without any way to distinguish what key was actually pressed. Games with rebindable inputs are pretty much restricted to the alphanumeric/modifier keys on non-QWERTY keyboards.

A possible (and previously suggested) solution is to provide direct scancode/VK/KeySym values in sf::Event and allow optionally passing them to a function like sf::Keyboard::isKeyPressed(), as this would at least allow keys to be distinguished locally. An API addition like this shouldn't break any existing code.

The issue is marked as "Milestone: 2.2", but unfortunately, there don't seem to be any pull requests to improve this behavior. I've made a personal workaround/hack that simply adds a systemCode member to the keyboard (and mouse) event struct, but it's undocumented/ugly, slightly buggy on Linux when modifiers are involved, and completely untested on Windows. Still, I'll try my best to contribute if I can.

Anyway, the issue may not exactly be critical, but it is bothering me quite a bit because I'm particularly affected by it.

[Laurent]

The scancode will be added in 2.2, yes. This won't solve everything (key codes will still be unreliable), but at least it will allow dynamic rebinding of keys in games, which is in my opinion the most common use case that suffers from this issue.

For those interested in this issue, there's a full discussion about possible solutions here:
http://en.sfml-dev.org/forums/index.php?topic=13692.0

[The Terminator]

I definitely agree with the technology preview of iOS and Android. I think that any API breaks should wait until SFML 3.

[eXpl0it3r]

My plans are to integrate the ios/android branch, even if not 100% stable. As long as the public API is stable, it doesn't hurt to include these ports as a "technology preview" in SFML 2.2.

Will the documentation & tutorial be written with the SFML 2.2 release? I think especially important is a tutorial on how to set things up, because the lack of a good one is what's keeping me from testing the Android API...

Any ideas for the audio/licensing issue?

Also I've heard a report saying the Android version isn't buildable on Windows at the moment?

So basically I open this thread to get more feedback from you, users. What do you think should be integrated into SFML 2.2? What critical bugs should be fixed? Keep in mind that "soon" means that we'll work on important / critical tasks only, don't start to suggest tons of new features here

Keyboard handling + mouse lock. Plus at best any open non-API breaking issue on GitHub.

[Laurent]

Will the documentation & tutorial be written with the SFML 2.2 release?

Of course.

Any ideas for the audio/licensing issue?

I'll contact the libsndfile author... again... but I'm not very optimistic.

Also I've heard a report saying the Android version isn't buildable on Windows at the moment?

I can't answer Android questions, I'm still waiting for an update from Jonathan.

Keyboard handling + mouse lock.

Mouse lock can be interesting, indeed. And there are pull requests pending if I'm right.

Plus at best any open non-API breaking issue on GitHub.

Nexus is already working on some of them

[Nexus]

We also considered merging the blendmodes branch to master. What do you think?

I plan to fix the bugs listed here, but I'll need some feedback on the platform-specific ones (see discussion).

There are also several bug reports related to windowing on Linux, but a lot of them aren't clearly investigated or reproduced. If somebody would like to help here, that would also be nice

[paupav]

Please don't release it so fast since obviously it takes for Ubuntu repository a while to get updated packages.

[Jesper Juhl]

There are also several bug reports related to windowing on Linux, but a lot of them aren't clearly investigated or reproduced. If somebody would like to help here, that would also be nice

I can take a look at reproducing and investigating some of those during the weekend.

[infinitebox]

Keyboard handling + mouse lock. Plus at best any open non-API breaking issue on GitHub.

+1!!
Especially mouse lock, would've saved me quite a bit of time and ugly workarounds in my last project.

[eXpl0it3r]

Maybe it motivates someone:
(from a private email)

SDL is C so I have to wrap it, but I need very little from it (just windowing and events; otherwise I talk to OpenGL directly).  According to my understanding, SFML does not support input grabbing (i.e. confining the mouse cursor to a region of the screen) which I want.  If they were equivalent in power I might think about switching, but that would consume time.

[select_this]

There are also several bug reports related to windowing on Linux, but a lot of them aren't clearly investigated or reproduced. If somebody would like to help here, that would also be nice

I can take a look at reproducing and investigating some of those during the weekend.

I can also help with this, but not until after 13th April as I'm on holiday in France until then. If anything's left over at that point (assuming that SFML 2.2 hasn't been released in the interim) then I can pick some up too.

[Nexus]

Maybe it motivates someone:

Is it really Mr. STL himself? Stephan T. Lavavej is known for his great contributions to the C++ language. Out of interest, may I ask in which context he wrote that e-mail?

SFML does not support input grabbing (i.e. confining the mouse cursor to a region of the screen)

He mentions a "region of the screen". Is the idea that the mouse cursor is not only kept inside the window, but inside a sub-rectangle of it? Does SDL allow that?

I can take a look at reproducing and investigating some of those during the weekend.

I can also help with this, but not until after 13th April as I'm on holiday in France until then. If anything's left over at that point (assuming that SFML 2.2 hasn't been released in the interim) then I can pick some up too.

Great, thank you both! Anyway, it will certainly take some time until the remaining bugfixes and features planned for SFML 2.2 are implemented.

[eXpl0it3r]

Is it really Mr. STL himself? Stephan T. Lavavej is known for his great contributions to the C++ language. Out of interest, may I ask in which context he wrote that e-mail?

Yes, yes it is. Well when I intended to write the email I didn't even realize it was S.T.L. until I retrieved the email address.
He's the one behind the MinGW builds on nuwen.net - it's his website and it took me way too long to realize that... The reason I contacted him was for asking whether he would be interested in adding SFML to his supported libraries, but since he uses SDL, he didn't want to.

He mentions a "region of the screen". Is the idea that the mouse cursor is not only kept inside the window, but inside a sub-rectangle of it? Does SDL allow that?

No idea, he probably just over generalized. SDL seems to lock the mouse inside the window, which is what SFML should go for as well.