SFML community forums
General => General discussions => Topic started by: Laurent on April 01, 2014, 12:40:32 pm
-
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 ;)
-
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.
-
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 (https://github.com/SFML/SFML/issues/7) 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.
-
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
-
I definitely agree with the technology preview of iOS and Android. I think that any API breaks should wait until SFML 3.
-
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. ;)
-
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 ;)
-
We also considered merging the blendmodes branch to master. What do you think?
I plan to fix the bugs listed here (https://github.com/SFML/SFML/issues?labels=bug&milestone=8&page=1&state=open), 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 :)
-
Please don't release it so fast since obviously it takes for Ubuntu repository a while to get updated packages.
-
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.
-
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.
-
Maybe it motivates someone: :D
(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.
-
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.
-
Maybe it motivates someone: :D
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.
-
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. ;D
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 (http://gamedev.stackexchange.com/a/33554) lock the mouse inside the window, which is what SFML should go for as well.
-
Wow! These are fantastic news!
Personally I am really looking forward to the new blending modes! One problem I haven't run into myself is the improved key handeling. But a lot of people seem to have trouble with it and I find it very important!
Other than that I am curious to what else 2.2 will bring. Personally I would love to see some minor (but really old!) bugs being fixed. Like this one (https://github.com/SFML/SFML/issues/203) or this one (https://github.com/SFML/SFML/issues/371).
I will try to find some time soon, to finish my pull request (https://github.com/SFML/SFML/pull/525) to get/set the window focus.
Hope to see SFML 2.2 soon :)
-
Other than that I am curious to what else 2.2 will bring. Personally I would love to see some minor (but really old!) bugs being fixed. Like this one (https://github.com/SFML/SFML/issues/203) or this one (https://github.com/SFML/SFML/issues/371).
Not sure, but they seem to require some API change, so I guess they are not suitable for SFML 2.2.
-
Concerning #371, the original issue (consistent reset in sf::Window::create()) will be fixed for SFML 2.2, as indicated by the milestone. The setting of styles without window recreation is also an interesting feature, but I think we should reconsider it for SFML 2.3.
I'm not sure about #203 and what it would exactly involve.
-
I'm just going to bring this up, it is something I always have liked to seen implemented. Using the view/rendertexture trick can only get you so far... :)
https://github.com/SFML/SFML/issues/1 (https://github.com/SFML/SFML/issues/1)
-
#1 is unlikely to be added, since we didn't even start to think about a possible design and implementation.
-
I just noticed this thread and it's really good timing because:
1. I would like to replace my OOIS code by either SDL or SFML;
2. Ogre3D people are considering switching to SDL or SFML too (instead of OIS and custom windowing code), but SDL is maintained by people at Valve so it looks like a safer long-term bet, while SFML is far nicer on composability and simpler code. In the end, an experiment using SDL is going on and I think have been merged. The discussion is there: http://ogre3d.org/forums/viewtopic.php?f=4&t=79237
3. The STL mail is good feedback too.
Basically, SFML is a very close challenger to SDL when it's used as basic layer for the windowing and input system, and that's a good thing but it's not yet the best long-term choice.
I prefer SFML personally, and I target only desktop in my current game so I'm almost sure I'll use it instead of SDL, but frankly on the long term it seems that SDL is always a best bet (until Valve people or other people related to game dev are starting to contribute).
Now, the important additional feedback that you can get from Ogre:
If the windowing system could be separated from the input system (maybe in an optional way?), it would allow a better composability, for example when you want the graphic rendering system to use a specific windowing system, and a very different input api, all sharing the same window handle from the windowing system.
Also, lack of force feedback info in the input.
-
To be honest, SDL is much more mature (= feature rich and robust) than SFML in input handling and events. I'm glad the Ogre team chose it.
Separating input and windowing is not a bad idea... let's keep that for later.
-
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 :)
Could you point out which ones are those?
-
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 :)
Could you point out which ones are those?
I found the following, but some may be duplicates. Pull requests are in there as well.
https://github.com/SFML/SFML/issues/564
https://github.com/SFML/SFML/pull/425
https://github.com/SFML/SFML/issues/535
https://github.com/SFML/SFML/issues/508
https://github.com/SFML/SFML/issues/129
https://github.com/SFML/SFML/issues/490
https://github.com/SFML/SFML/issues/436
https://github.com/SFML/SFML/pull/260
https://github.com/SFML/SFML/issues/103
https://github.com/SFML/SFML/pull/319
https://github.com/SFML/SFML/issues/200
https://github.com/SFML/SFML/issues/274
-
You can also filter by the labels "bug" and "sfml-window" ;)
-
True... I'm gonna give my excuse as: "I wanted to make sure to get everything."
:P
-
Personally, all I wanted from 2.2 was a fix for #437 (https://github.com/SFML/SFML/issues/437) and the mobile ports, so this is awesome news for me.
-
Features I'm really looking forward:
- Mouse lock/grab (issue #394 (https://github.com/SFML/SFML/issues/394))
- Allow alt-tab in fullscreen mode in Linux (pull #425 (https://github.com/SFML/SFML/pull/425))
-
I'm really looking forward to:
- International keyboard support
- Selecting the SFML window by clicking inside the window's dimensions, instead of the title bar.
- iOS/Andriod Port
-
Getters for OpenGL object handles please :)
-
For me the most important feature of next SFML would be iOS/Android ports. By the way, would those ports allow me to run my SFML game in Raspberry pi?
-
Yes, Raspberry Pi is supported.
-
There is another small and really old thing that I would love to see implemented! It's the ability to choose the monitor for a fullscreen window. #188 (https://github.com/SFML/SFML/issues/188)
-
Multi-monitor support will come, but it most likely won't make it into 2.2, given that it requires quite a bit of work on each platform.
-
It's the ability to choose the monitor for a fullscreen window. #188 (https://github.com/SFML/SFML/issues/188)
This is already working in SFML.Net :)
-
This is already working in SFML.Net
No it is not. SFML.Net is just a binding, it doesn't have more features than SFML.