SFML 2.1

[Laurent]

I'm happy to announce the release of SFML 2.1

It's a bug fix release, so don't expect anything new.

I'll focus on implementing new stuff in the next release, SFML 2.2.

[Nexus]

Nice

Are there specific plans for SFML 2.2?

[Laurent]

Except iOS and Android ports, nothing is decided yet.

[Lo-X]

Except iOS and Android ports, nothing is decided yet.

Just a question : for minor versions you don't want any modification in the API right ? Or things can be added/altered ?

[FRex]

Are there specific plans for SFML 2.2?

Yes, LaurentScript, it'll be AWESOME, it'll be garbage collected, dynamically strongly duck typed, imperative, iterative, nooberative, structural, functional scripting language for use with Irrlicht(finally bringing 3D into SFML!!), totally foolproof, with syntax mix of C#, Perl, COBOL and Brainfuck with most important sigil being euro sign, I can't wait! 

On a more serious note: I'm glad it didn't take another few years like jump from 'official but unattended and obsolete'1.6 to 'stable, better, faster, easier but still RC' 2.0 did, why weren't there 1.7 through 1.9 thought? Did old rendering and transformation path got too cumbersome compared to light everything-as-array-of-vertices + states we have now and there has to be major version number up for something like that (and/or API) to change?

[Laurent]

Just a question : for minor versions you don't want any modification in the API right ? Or things can be added/altered ?

Things can be added, but I want to keep API compatibility. In other words, a SFML 2.x code should compile and run with any older SFML 2 version.

On a more serious note: I'm glad it didn't take another few years like jump from 'official but unattended and obsolete'1.6 to 'stable, better, faster, easier but still RC' 2.0 did, why weren't there 1.7 through 1.9 thought? Did old rendering and transformation path got too cumbersome compared to light everything-as-array-of-vertices + states we have now and there has to be major version number up for something like that (and/or API) to change?

Between 1.6 and 2.0, API compatibility was not preserved, so 2.0 was a new major version.

And 2.0 is not supposed to be the version next to 1.9. In fact these numbers have nothing to do; if an API-compatible version was released after 1.9, it would be 1.10.

[FRex]

I see, so major numbers are bumped for (api) overhauls and minor ones are bumped for fixes and small changes.

[Rachen]

I'm very new to SFML(downloaded 2.0 yesterday and still working on getting everything setup correctly), but I noticed 2.1 doesn't come with a CMakeLists.txt file like 2.0 does.  Can I just use the 2.0 CMakeLists.txt file in it's place or am I missing something entirely? 

[eXpl0it3r]

I'm very new to SFML(downloaded 2.0 yesterday and still working on getting everything setup correctly), but I noticed 2.1 doesn't come with a CMakeLists.txt file like 2.0 does.  Can I just use the 2.0 CMakeLists.txt file in it's place or am I missing something entirely? 

Not sure what you were looking at. There are binary packages, where SFML was already built and thus doesn't include the source, which also means there isn't a CMakeLists.txt.
But then you can download the full source with the CMakeLists.txt, but without the binaries so you'll have to build it yourself.

http://www.sfml-dev.org/download/sfml/2.1/
Top: Binaries
Bottom: Source

[XeRaCKeR]

Hi, there's an issue with sf::Event in Win7 x64bits

#include <SFML/Graphics.hpp>
#include <iostream>

int main()
{
    sf::RenderWindow window(sf::VideoMode(800,640,32),"My window");
    sf::Event event;

    while(window.isOpen())
    {
        while(window.pollEvent(event))
        {
            switch(event.type)
            {
                case sf::Event::Closed:
                    std::cout << "Don't close me! :(" << std::endl;
                    break;
                default:
                    break;
            }
        }
    }
}

ALT+F4 only returns sf::Event::Closed state when mouse cursor is outside of sf::RenderWindow

EDIT: Another issues:

• sf::Text just doesn't work unless you set the font

[Laurent]

sf::Text just doesn't work unless you set the font

Yes, this is the expected behaviour. There's no more default font (already in 2.0).

[Lo-X]

I cant find the post anymore, but I remember a feature request for few more features about collision between shapes. Dunno if it can really be part of SFML or if too specific, but it would be nice to have that in a next version

[XeRaCKeR]

sf::Text just doesn't work unless you set the font

Yes, this is the expected behaviour. There's no more default font (already in 2.0).

I was able to use sf::Text without set a font in 2.0, lol, nvm.

What about the sf::Event::Closed issue? will be fixed soon?

EDIT: Another issue:

           case sf::Event::GainedFocus:
                std::cout << "The window gained focus." << std::endl;
                break;
            case sf::Event::LostFocus:
                std::cout << "The window lost focus." << std::endl;
                break;

sf::RenderWindow doesn't gain focus unless you click the titlebar, clicking inside the sf::RenderWindow doesn't work :/

Seems there's some bit issues with sf::Event, but at least, the taskbar bug has been fixed, nice fix, really. 

Regards

[Laurent]

I was able to use sf::Text without set a font in 2.0, lol, nvm.

No, really, there's no default font in SFML 2.0 final (maybe you got an old revision).

What about the sf::Event::Closed issue? will be fixed soon?

I just tested it, and I can confirm that there is a new bug. Damn... whenever you fix one bug, a new one pops up to replace it

sf::RenderWindow doesn't gain focus unless you click the titlebar, clicking inside the sf::RenderWindow doesn't work :/

Ok, this is also related to the first bug. So this is worse: you fix one bug, two new bugs appear.

For the record, these two bugs are caused by the SetCapture function, which was added to solve issue #225.

[MorleyDev]

I'm starting to wonder if perhaps SFML would benefit from a suite of integration/acceptance tests to run. I know graphics and such are notoriously difficult to test, but still...

I may give it a shot just to see how feasible this would be. I've already integrated SFML into my automated continuous integration set-up, so may just give writing a "SFML.test" project a shot to drop it between my SFML.build and SFML.package jenkins jobs xD

Obviously not low-level unit tests, but maybe just something that fires up a bunch of sample programs and does a mix of automated and maybe some manual checks from the runner to verify the expected things to happen...well, happened.

It'd not be too difficult for me to do this for Windows at least, it's pretty easy to hijack the keyboard and mouse and just force some inputs using the Windows API, but I've not enough experience with this kind of thing on other OSes. With any luck a framework already exists.

It's also something I think would be required if ever SFML were to have more "community-driven development" for whatever reason, since I can't be the only one who likes to be able to code fearlessly, and the lack of tests giving me some assurance I haven't somehow broken everything and missed it, my biggest fear, would be the main deterrent for me taking part in that community-driven development.