This implements #604. It's a rebase of feature/no_libsndfile_osx onto master (which includes feature/no_libsndfile) so be extra careful when proofreading it. Hopefully I haven't made any mistake but there were a lot of conflicts so...

What's done & what's to be done:

• [x] Android (all libs included)
• [x] Android – make loading sound compatible with APK
• [x] iOS (all libs included)
• [x] Linux (no binary to be provided)
• [x] OS X (all libs included)
• [x] Window (all libs included)

It also includes the base step toward #620.

Supersedes #784.

Thanks to @fundies for the initial draft implementation. I originally wanted to attribute the commit to him, but there were simply too many changes in the end.

Resource leaks should be gone now, and general code style is fixed up. Like #784, this is still missing the OS X implementation. Hopefully @mantognini or someone else can fill in the gaps here and here. It can't be nearly as horrible as the Windows or Unix implementations. :stuck_out_tongue: This might help a bit.

This implements #269.

TODO list:

• [x] Have config file generated on all platforms
• [x] Support debug/release config
• [x] Have no absolute path in generated config files on Linux / Windows / macOS / iOS? / Android?
• [x] Export internal dependencies in case of static build (ie. remove the need for SFML_DEPENDENCIES)
• [x] Support for REQUIRED/QUIET options of find_package()
• [x] Framework install path
• [x] SFML_DOC_DIR
• [x] Remove FindSFML.cmake once SFMLConfig supports everything from it
• [x] Exhaustive testing! ==> see https://en.sfml-dev.org/forums/index.php?topic=23676.msg161479#msg161479

Out of scope:

• Compatibility with split Linux packages
• Support for components

=============

I've started doing the changes to support config file generation. At the moment this is working at least for me on macOS with frameworks. I expect it to work on other platforms too because it reuses the definitions of current SFML targets. This implies a LOT of changes though so I would like your feedback before going on.

Especially I have replaced all the listing of dependencies with calls to target_link_libraries() and target_include_directories() for 3 reasons:

• this avoids redoing what CMake already does (target_link_libraries() and target_include_directories() already handle lists)
• this makes it easier to group the full setup (include+link) of each dependency
• this will allow specifying which dependencies must be public in case of static linking (what SFML_DEPENDENCIES currently does in FindSFML.cmake), same eventually if compile definitions or include dirs must be exported (currently only the root include dir of SFML is exported)

In terms of usage right now (example from sfeMovie) of course without any FindSFML.cmake:

find_package (SFML 2.3 COMPONENTS graphics window system audio REQUIRED)
target_link_libraries(sfeMovie PRIVATE sfml-graphics sfml-window sfml-system sfml-audio)

I didn't expose yet the fact that sfml-graphics depends on sfml-window and sfml-system. Could be done and would allow writing only target_link_libraries(sfeMovie PRIVATE sfml-graphics sfml-audio) Dunno yet if we want that though.

If you want to look at what the generated config looks like for now: http://yalir.org/files/SFML/ It gets installed in /usr/local/lib/cmake/SFML by default.

References

https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-packages https://cmake.org/cmake/help/latest/command/find_package.html https://cmake.org/cmake/help/latest/command/export.html https://cmake.org/cmake/help/latest/module/CMakePackageConfigHelpers.html https://github.com/SFML/SFML/compare/master...SrTobi:support-config-file-packages

Related issues

https://github.com/SFML/SFML/issues/758 https://github.com/SFML/SFML/issues/937

SFML Tasks

• [x] Check for forgotten discussion points
• [x] Review code

This is my code, that I promised in this forum thread. It is pretty straight forward. Here is some example code to test with:

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

int main()
{
    sf::RenderWindow window(sf::VideoMode(800, 600), "Character Spacing Example");
    window.setFramerateLimit(60);

    // load font
    sf::Font font;
    if(!font.loadFromFile("BilboSwashCaps-Regular.otf"))
    {
        std::cerr << "Failed to load font!" << std::endl;
        return 1;
    }

    // setup the texts
    sf::Text normalText("SFML rocks! 123", font);
    normalText.setCharacterSize(100);
    normalText.setPosition(30, 10);
    normalText.setStyle(sf::Text::Style::Bold);

    sf::Text smallText("SFML rocks! 123", font);
    smallText.setCharacterSize(30);
    smallText.setPosition(30, 150);
    smallText.setStyle(sf::Text::Style::Bold);

    sf::Text stretchedText("SFML rocks! 123", font);
    stretchedText.setCharacterSize(100);
    stretchedText.setPosition(30, 200);
    stretchedText.setStyle(sf::Text::Style::Bold);
    stretchedText.setLetterSpacing(6.f);

    sf::Text smallStretchedText("SFML rocks! 123", font);
    smallStretchedText.setCharacterSize(30);
    smallStretchedText.setPosition(30, 350);
    smallStretchedText.setStyle(sf::Text::Style::Bold);
    smallStretchedText.setLetterSpacing(1.f);


    // run the program as long as the window is open
    while (window.isOpen())
    {
        // check all the windows events
        sf::Event event;
        while (window.pollEvent(event))
        {
            // "close requested" event: we close the window
            if (event.type == sf::Event::Closed)
                window.close();

            else if (event.type == sf::Event::KeyReleased) {
                // close if escape key was pressed
                if (event.key.code == sf::Keyboard::Escape) {
                    window.close();
                }
            }
        }

        // clear the window to black
        window.clear();

        // draw text
        window.draw(normalText);
        window.draw(smallText);
        window.draw(stretchedText);
        window.draw(smallStretchedText);

        // display the windows content
        window.display();
    }
    return 0;
}

The font Bilbo Swash Caps Regular is taken from here.

This pull request is based on https://github.com/LaurentGomila/SFML/pull/525 by @Foaly.

It extends the sf::Window public interface with two methods:

• void requestFocus() to give the window the focus
• bool hasFocus() const to check whether the window is currently focused

I tested the functionality on Windows 8.1 and Ubuntu 12.04. Here's a simple test program, based on Foaly's:

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(200, 200), "SFML works!");
    window.setFramerateLimit(60);

    sf::Clock clock;
    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
            if (event.type == sf::Event::KeyReleased && event.key.code == sf::Keyboard::Escape)
                window.close();
        }

        if (clock.getElapsedTime() > sf::seconds(2))
        {
            window.requestFocus();
            clock.restart();
        }

        window.setTitle(window.hasFocus() ? "Focused" : "Lost");
        window.clear(window.hasFocus() ? sf::Color::White : sf::Color::Black);
        window.display();
    }
}

I haven't gotten feedback concerning the X11 check as suggested by @FRex, it would be nice if somebody could have a look at commit 2df07b2eb61a9603bedb095dff73a042c4f26453.

Related to #394.

Adds sf::Window::setCursorGrabbed implementations for Linux, Windows and Mac OS X. Android and iOS devices have a «not applicable» implementation.

Requires testing on:

• [x] Linux
• [x] Windows
• [ ] OS X
• [ ] iOS (build check only)
• [x] Android (build check only)

Here are a few scenarios to be tested:

1. Grabbing the cursor works when the window has the focus.
2. When grabbed, the cursor should not be able to leave the window.
3. Closing the window should release the cursor.
4. When grabbed, the window should not be resizable by dragging one of its sides.
5. When switching to another app, the cursor should be released and re-grabbed when reactivating the SFML app.
6. If the cursor is outside the view when it is grabbed the cursor should be projected into the window (and thus generate a mouse in event).
7. The user should not be able to move fast the cursor and click outside the window to activate another application.
8. The user should not be able to use the window bar to move, minimize, maximize or close the window.
9. Fullscreen windows should grab the cursor correctly with 2+ monitors.
10. Programmatically moving the window should keep the cursor inside the rendering area in case the cursor was grabbed and properly update the "grab area" to match the new window position.
11. Like 10. but when programmatically resizing the window.

This code can be useful for testing.

Below is the list of issue from the above list that need to be fixed before merging this PR:

• Linux: 5 (should be fixed, confirmation needed)
• OS X: N/A
• Window: N/A
• iOS: N/A
• Android: N/A

Regarding OS X: [Updated on 25/4/2016] ~~The current impl is not bad but still an approximation of the feature (test n° 7 is somewhat supported and n° 8 is not supported at all) . It seems really hard to do it on Mac. Other libs (e.g. SDL) have even more bugs or undesired behaviour than this implementation. However, a lot of tricks are used which is not nice at all for future modifications of SFOpenGLView (among other things).~~

~~Commit d16d38e contains a more detailed explanation of the known issues (in commit message and comments in the code itself). I'm reluctant to include this commit in SFML codebase because it will considerably increase the complexity of the code and make it really hard to maintain. All that to "only" workaround a stupid corner case... Please let me know what you think.~~

~~An alternative for games that need grabbing would be to hide the cursor and use relative motion, preventing the cursor to actually move. This would involve much fewer corner cases in the implementations. Actually, SDL also provides this alternative.~~

Please refer to commit 4f5baa53ece0f8777c23d1027098ceff7c2cea3c for detailed description of the workarounds involved.

After working a bit with SFML, I noticed that I couldn't set any custom loop points for sounds, and I need them for a game I'm working on. I spotted issue #177 sitting around, so I figured I would try implementing myself.

For sf::Music / sf::SoundStream, I added a feature to detect a loop point and cut off the streaming of the buffer, and a pair of virtual functions that can allow sf::SoundStream to let its derived class decide where to seek upon looping. It's accomplished entirely within those two classes without doing anything too funny with OpenAL, and I'm happy with what I managed to accomplish with it.

~~For sf::SoundBuffer / sf::Sound, I ran into some more constraints. OpenAL-Soft has a way to set loop points, but it's not a well-documented feature, and it is also a buffer trait, rather than a source trait. It has a few more restrictions on the allowable values compared to the Music version because of this. It uses an "enum" value called AL_LOOP_POINTS_SOFT defined in "alext.h", which was present in SFML but not included, and I figured it was fair game to use. If not, then I can take the SoundBuffer implementation out.~~

The inline documentation will explain any interface differences, but they're roughly the same, with getLoopStart(), getLoopEnd(), setLoopPointsFromTime(), and setLoopPointsFromSamples(). Three of those work with sf::Time, to keep everything consistent, the fourth is if you have an exact sample position you want to use.

I hope this isn't frowned upon, but for testing, I augmented the SFML Sound Example to include some additional playings of the resource sounds, and demonstrating some of the extra features of the Music implementations. At least it should be easy to build and test. If any modification or more proof-of-functionality is needed, please let me know!

It seems the text rendering APIs available in SFML 2.0 currently aren't able to render text with enough hinting to be legible at lower resolutions. Having text < 20pt is a must for some areas of my interface elements I'm making with SFML, so this is a large issue at the moment.

Here's an example of what I'm talking about:

It seems SFML does have some kind of support for bitmap fonts, it's stated on the website as a feature: "Easy manipulation of graphical text through bitmap fonts". I can't seem to find anything in the documentation about this though, does this feature really exist?

It'd be nice if one of the solutions was approached, either the inbuilt font rendering being worked on to be more capable, or bitmap font support being added so those that do wish to use small fonts can do so without rendering issues.

Ironically it seems that even at 40pt the rendering engine can't handle some of the more fine hinting required by the current font I'm using, this can be seen in the 'i' of Exception, and various rounded edges of the 'rounder' letters like 'p' and 'o'.

Access Violation error occurs int the destructor of sf::AudioDevice on Windows XP SP3. It doesn't occur on Windows 7 and Windows Vista.

Here is the instruction pointed by the visual C++ 2008 debugger:

Code:

AudioDevice::~AudioDevice() 
{ 
    // Destroy the context 
    alcMakeContextCurrent(NULL); 
    if (audioContext) 
=>           alcDestroyContext(audioContext); 

    // Destroy the device 
    if (audioDevice) 
        alcCloseDevice(audioDevice); 
} 

The error can be reproduced with this simple code :

#include <SFML/Audio.hpp> 

int main() 
{ 
    sf::Sound Sound; 

    return EXIT_SUCCESS; 
} 

This problem was first discussed in this post of the french forum : http://www.sfml-dev.org/forum-fr/viewtopic.php?t=3443

Considering all the requests over the years for outlined text (and the totally hackish workarounds) and also that my current project will definitely need this at some point, I went ahead and implemented it. I made the PR for code review.

Some key points are the following.

• Outlined glyphs are stored in the same page as normal glyphs (can be changed if this is deemed that it will fill up the page texture too fast).
• Text::[set|get]Color(...) is now marked as deprecated, instead everyone should use Text::[set|get]FillColor(...)
• Font::getGlyph(...) has a new parameter, outline thickness which is defaulted to 0 (to avoid API breakage). The parameter determines how thick the outline will be in pixels.
• Since outlined glyphs are stored in the same page/texture the key type has been changed to Int64 to continue being unique now that the outline thickness is part of the key.
• I refactored Text::ensureGeometryUpdate() and split the duplicated code to append vertices to separate functions ::addLine(...) and ::addGlyphQuad(...). These can be renamed if someone could think of more appropriate names.
• ~~Outline thickness is unsigned, I don't see any easy ways with freetype to make the outline protrude inwards with a negative thickness.~~ It is a float, but a negative value causes distorted rendering.
• Nothing should change with the current rendering of text if the user decides not to use outlines.

As stated before, please review this and give some feedback.

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window({ 700, 400 }, "Outline test");
    window.setVerticalSyncEnabled(true);

    sf::Font font;
    font.loadFromFile("C:/Windows/Fonts/arial.ttf");

    sf::Text text(L"\u0476ZyG\noLPfkdf", font, 140);
    text.setPosition({ 20, 20 });

    text.setFillColor(sf::Color::Red);

    text.setOutlineThickness(5);
    text.setOutlineColor(sf::Color::White);

    text.setStyle(sf::Text::Underlined | sf::Text::Italic | sf::Text::StrikeThrough);

    while (window.isOpen())
    {
        sf::Event e;
        while (window.pollEvent(e))
        {
            if (e.type == sf::Event::Closed)
                window.close();
        }

        window.clear();

        window.draw(text);

        window.display();
    }
}

Recreated from #842

This is ready for a code review, hoping for a SFML 2.4 inclusion. This implements #1, yes the very first issue. :smile:

I based my branch on /feature/gl_dev_new due to the OpenGL changes. Clipping is done with the stencil buffer which gets enabled when a mask is applied to the render states.

Some points from #1 are answered below about this implementation.

And do we clip in scene coordinates or in window coordinates?

Clipping is done in scene coordinates.

However since it can be disabled (and is currently not enabled by default) in the context settings.

It is now enabled by default in the context and render texture constructors.

it implies that the user can disable clipping masks, without even knowing it. So this must be at least well documented, and even enforced if possible.

It is now noted in the documentation that disabling stencil buffer will disable clipping masks. As for enforcing it? Its not really needed, if the user disables it - it is their fault because it is clearly stated.

So the main problem is to decide what we use to define the clipping area. We could start with a const sf::Drawable* to have maximum flexibility.

Clipping area is defined by the sf::ClippingMask class which is a container for multiple const sf::Drawable* pointers.

Another question is: do we allow only one active mask, or do we provide the ability to add multiple masks?

Only 1 mask is active at one time, but it can be defined by multiple drawables.

As with my other PR (#840), please review and test and then give feedback. Even textures with alpha channels are supported.

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window({ 800, 600 }, "Clipping Mask Test");
    window.setVerticalSyncEnabled(true);

    // create a circle for part of the clipping mask
    sf::CircleShape keyholetop(50);
    keyholetop.setOrigin({ 50, 50 });

    // create a square for part of the clipping mask
    sf::RectangleShape keyholebody({ 36, 150 });
    keyholebody.setOrigin({ 18, 0 });

    // create the clipping mask
    sf::ClippingMask clipmask;

    // add the shapes to the clipping mask
    // sf::ClippingMask behaves like sf::VertexArray
    // so you can append any sf::Drawable to the mask
    // the mask will not copy the sf::Drawable, it only stores a pointer
    clipmask.append(keyholetop);
    clipmask.append(keyholebody);

    sf::Texture background;
    // use any background image
    // I used the image from opengl example
    background.loadFromFile("sfml/examples/opengl/resources/background.jpg");

    sf::Sprite backgroundsprite(background);

    // set a clipping area
    // for this example exlude the area 50px from the borders
    window.setClippingArea({ 50, 50, 700, 500 });

    while (window.isOpen())
    {
        sf::Event e;
        while (window.pollEvent(e))
        {
            if (e.type == sf::Event::Closed)
                window.close();
        }

        // get mouse position
        sf::Vector2f mousepos = window.mapPixelToCoords(sf::Mouse::getPosition(window));

        // update the mask position
        clipmask.setPosition(mousepos);

        //assign the clipping mask to the window
        window.setClippingMask(clipmask);

        window.clear(sf::Color::Blue);

        window.draw(backgroundsprite);

        window.display();
    }
}

I just updated the API. I removed the clipping mask from the render states and instead added function the render target class for setting the mask. Also all clipping is now cached instead of redrawn every time.

And I will say it again: Please test and give feedback - even if you don't test this branch, at least comment on the API design, thanks :smile:

There was a total of 6 functions added to the render target class.

clearClipping[Area|Mask]();
setClipping[Area|Mask](...);
getClipping[Area|Mask]();

Clipping masks are the same as the previous commits, basically a list of drawables that allow users to define custom shapes / pixel based masks. The masks are implemented with the stencil buffer.

Clipping areas on the other hand are limited to a single IntRect that is defined in window coordinates. The clipping area is implemented using glScissor(...) which should provide faster, simpler clipping for those who just need it for basic GUIs.

The clipping mask on the other hand is heavier and uses the stencil buffer for clipping. It works in scene coordinates and is used for more complex masks.

Both clipping modes are applied like the view is. To set a clipping mode you first call setClippingXXX(...) with the appropriate parameters. The clipping mode will be cached until it is either cleared or updated (another set call).

Subject of the issue

Many interfaces and class members use unsigned int. This type was seemingly picked as a C++03 shorthand for std::size_t or at least an approximation for std::uint32_t even though unsigned int isn't necessarily 32 bits wide. If our intent is to use 32 bit (or 64 bit) unsigned integers, let's use a type which better expresses and guarantees our intent.

A similar argument could be used for any uses of short, int, or long although are not nearly as pervasive in the interface so I'm not necessarily calling those out.

See this cppreference page for more information on the various possible widths of integral types.

Thanks a lot for making a contribution to SFML! 🙂

Before you create the pull request, we ask you to check the follow boxes. (For small changes not everything needs to ticked, but the more the better!)

• [x] Has this change been discussed on the forum or in an issue before?
• [x] Does the code follow the SFML Code Style Guide?
• [ ] Have you provided some example/test code for your changes?
• [ ] If you have additional steps which need to be performed list them as tasks!

Description

Please describe your pull request.

resolves #2312

Tasks

• [x] Tested on Linux
• [ ] Tested on Windows
• [ ] Tested on macOS
• [ ] Tested on iOS
• [ ] Tested on Android

• [x] Has this change been discussed on the forum or in an issue before? Issue #2224
• [x] Does the code follow the SFML Code Style Guide?
• [ ] Have you provided some example/test code for your changes?
• [ ] If you have additional steps which need to be performed list them as tasks!

Description

I will be empty structs to namespaces.

This PR is related to the issue #

Tasks

• [ ] Tested on Linux
• [x] Tested on Windows
• [x] Tested on macOS
• [ ] Tested on iOS
• [ ] Tested on Android

How to test this PR?

Describe how to best test these changes. Please provide a minimal, complete and verifiable example if possible, you can use the follow template as a start:

// pending

Subject of the issue

sf::Sound does not play mono sf::SoundBuffer when previously played stereo sf::SoundBuffer.

Your environment

• Windows 11
• SFML 2.5.1
• MSVC 16.11

Steps to reproduce

I load an sf::SoundBuffer (a stereo sample) into my sf::Sound, play it, all good. Later I decide to recycle the sf::Sound in order to play another sf::SoundBuffer (a mono sample this time) and play that.

Expected behavior

I can hear the 2nd sample.

Actual behavior

I can't hear the 2nd sample.

Workaround

Just converting all my samples to stereo resolves the problem.

Description

This fix forces XResizeWindow to occur after the user is done resizing the window. If you use the test code I have provided, you will see that setSize is called after a resize event is done. Before this commit, setSize would run XResizeWindow, but since the user's mouse was still holding onto the window, the window would resize to whatever size the user's mouse is at. With my fix, XResizeWindow is GUARENTEED to occur once the user is done dragging the window.

Here is a video demonstrating my fix working: https://youtu.be/mLMVFbeuRIs

This PR is related to the issue #2124

Tasks

X11 LINUX ISSUE ONLY

• [x] Tested on Linux

How to test this PR?

After you install SFML, go ahead and compile, link, and run the code below. You will see that the resize event is seemingly not called.

Install my fix, compile, link, and run the code below. You will see the resize event being called and resizing the window.

#include <SFML/Graphics.hpp>
#include <SFML/Window.hpp>
#include <SFML/System.hpp>

int main() {
    sf::RenderWindow window(sf::VideoMode(200, 200), "SFML works!");

    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
            if (event.type == sf::Event::Resized) {
                const sf::Vector2u window_size(event.size.width, event.size.height);

                if (window_size.x < 200) {
                    window.setSize(sf::Vector2u(200, window_size.y));
                }
                if (window_size.y < 200) {
                    window.setSize(sf::Vector2u(window_size.x, 200));
                }
            }
        }

        window.clear();
        window.display();
    }

    return 0;
}

Subject of the issue

The C++ specification requires that 0 be returned if you reach the end of main so you never have to add return 0; or return EXIT_SUCCESS; as the last expression in your program. This pattern can be removed which also entails potentially removing #include <cstdlib> if this is the last place where that header is being used.