Topics

31

SFML development / SFML concurrency vs C++ standard

« on: March 13, 2017, 08:54:15 pm »

Info & Rules about this sub-forum

One of the bigger changes with C++11 was the introduction of concurrency classes.
In the past SFML had no choice but to create its own abstraction for threads, mutexes and locks. But with C++11 these classes are basically just duplicated.

Similar to the sf::Time & sf::Clock discussion, the questions are:

• Do we completely remove the SFML concurrency classes?
• Or do we keep the API but change the implementation.
• What are your arguments for either situation?
• Do you have any concerns about standard concurrency classes?

Here are two simple examples again for SFML and C++11. Let us know if you think there's a better example to show case the differences or if some important difference was left out.

(click to show/hide)

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

sf::Mutex mutex;

void func()
{
    mutex.lock();

    for (int i = 0; i < 10; ++i)
        std::cout << "I'm thread number one" << std::endl;

    mutex.unlock();
}

int main()
{
    sf::Thread thread(&func);
    thread.launch();

    mutex.lock();

    for (int i = 0; i < 10; ++i)
        std::cout << "I'm the main thread" << std::endl;

    mutex.unlock();
}

(click to show/hide)

#include <thread>
#include <mutex>
#include <iostream>

std::mutex mutex;

void func()
{
    mutex.lock();

    for (int i = 0; i < 10; ++i)
        std::cout << "I'm thread number one" << std::endl;

    mutex.unlock();
}

int main()
{
    std::thread thread(&func);

    mutex.lock();

    for (int i = 0; i < 10; ++i)
        std::cout << "I'm the main thread" << std::endl;

    mutex.unlock();

    thread.join();
}

Summary
There doesn't seem to be a reason to keep the SFML API as the standard API does provide the same functionalities.

32

SFML development / sf::Time & sf::Clock vs C++11 chrono

« on: March 08, 2017, 12:58:37 pm »

Info & Rules about this sub-forum

With C++11 we finally got access to <chrono> a native and thus cross-platform C++ standard library timing and clock functionalities.

SFML 2.x and earlier has introduced its own sf::Clock and later sf::Time classes to deal with time dependent functionalities internally but also as library features, useful in pretty much any application.

Questions are now:

• Should we completely drop sf::Time and sf::Clock?
  
• Or should we keep the classes but internally use <chrono>?
  
• What are your arguments for either situation?
• Do you have any concerns about <chrono>?
  

For comparison here are two simple clock example as one can probably find in many games. Let us know if you think there are better examples/implementations to show the API differences.

(click to show/hide)

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window{sf::VideoMode(800, 600), "SFML"};
    window.setVerticalSyncEnabled(true);

    sf::RectangleShape shape{{10.f, 10.f}};
    sf::Vector2f velocity{20.f, 20.f};

    sf::Clock clock;
    while (window.isOpen())
    {
        sf::Time dt = clock.restart();
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
        }

        shape.move(velocity * dt.asSeconds());

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

(click to show/hide)

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

int main()
{
    using clock = std::chrono::high_resolution_clock;

    sf::RenderWindow window{sf::VideoMode(800, 600), "SFML"};
    window.setVerticalSyncEnabled(true);

    sf::RectangleShape shape{{10.f, 10.f}};
    sf::Vector2f velocity{20.f, 20.f};

    auto last = clock::now();

    while (window.isOpen())
    {
        auto now = clock::now();
        auto dt = std::chrono::duration_cast<std::chrono::seconds>(now - last);
        last = now;

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

        shape.move(velocity * dt.count());

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

Summary

• Keep sf::Time
  
  • Internally use std::chrono::nanoseconds
    
  • Add conversion from and to std::chrono::duration
• Make sf::Clock a stopwatch

33

SFML development / C++ standards

« on: February 22, 2017, 05:09:38 pm »

Info & Rules about this sub-forum

SFML 2.x is currently stuck with C++03 and it's starting to show in various places. For SFML 3 we had decided already quite a while ago, that we will be using C++11. In the meantime however, C++14 has become widely spread and most compilers out there support all or all important features of the C++14 standard. While SFML 3 is in development for the next x months, one might even ask yourself, whether C++17 might an option.

In this discussion, we want to focus on what features of the new C++ standards SFML can make use of and how these language features should be applied. However, this discussion is not about whether standard classes such as std::thread/std::chrono should replace the SFML's equivalents; those will be discussed separately.

Here are some points that might aid as foundation for the discussion.

• C++11, C++14, C++17?
• Move semantics for resource classes
• Remove component-wise overloads in favor of initializer lists: setPosition(x,y) -> setPosition({x,y})
• Code simplification: smart pointers, type inference, range-based for, delegating/inheriting constructors, nullptr, lambda expressions, std::function, std::tuple
• [[deprecated]] attribute (C++14)

Let's start things off with a recently written list of questions by binary1248.

• When/Where do we use initializer lists? Everywhere possible, or only in certain scenarios?
• Uniform initialization? {} everywhere or () as it was in C++03?
• Almost always auto? Or are there cases when auto is not desired?
• When do we start using decltype instead of having to type out something that can't be auto deduced?
• Do we use generic lambdas (C++14)? Or C++11 non-generic lambdas?
• How do we format lambdas?
• Do we rather specify the lambda return type or static_cast a return value that causes ambiguity?
• I assume we make use of override everywhere where it makes sense?
• When do we use nullptr? Everywhere? Even when talking with OS APIs that use the NULL define?
• When do we make use of strongly typed enumerations? Everywhere? Or are there exceptions?
• Rule of Zero everywhere possible and Rule of Five elsewhere? :P (I am actually a firm believer of this.)

Related topics

• sf::Time & sf::Clock vs C++11 chrono
  
• SFML concurrency vs C++ standard
  
• sf::NonCopyable and =delete
  

Summary

• Certainly C++11
• Some features of C++14 depending on compiler support
• setXY({x, y})

C++14 features

• std::make_unique - High priority
  
• [[deprecated]] - Mid priority
  
• constexpr - Low priority
  
• generic lambdas - Low priority
  

Tasks

• Requires a study of language feature support on different compilers and compiler support on different platforms.

34

SFML development / Suggestions

« on: February 18, 2017, 12:28:08 pm »

Do you have an SFML development topic that you think should be discussed?
Feel free to leave a suggestion below!

But first, make sure to read and understand the following points:

• Features requests belong into the feature requests forum!
  
• This is a list of discussion topics, not what will be included in/applied to SFML 3.
• Avoid any kind of discussion in this thread.
• Make sure the topic wasn't already discussed.
• Make sure the topic wasn't already suggested.

Discussed Topics
General

• C++ standards
  

System

• Standard equivalents for sf::Time/sf::Clock
  
• Standard equivalents for sf::Mutex/sf::Lock/sf::Thread
  
• sf::NonCopyable and =delete
  
• Replacing/refactoring of streaming classes

Window

• Clipboard support
  

Graphics

• sf::Font: Abstraction and Bitmap Fonts
  
• How should SFML handle non-legacy shaders?
  

Suggested Topics
General

• Unified way to handle cross-platform code
• Different platforms (Windows Phone, Xbox, PS4, Web)
• Unit testing
• Error handling

System

• General loading/saving facilities

Window

• Better/modular backend/context handling
• Separate the contexts out from the Window
• Support multi-monitor setups
• Allow style/state changes without recreating window
• Improve keyboard handling
• Improve the joystick handling
• Full/better support for High-DPI displays and DPI awareness

Graphics

• Aggregation instead of inheritance-based design
• Investigate support for complex text layouts
• Make CircleShape, RectangleShape, and ConvexShape only be shapes, not drawables

Audio

• Single sound class with different resource backends (buffered or streamed)
• sf::AudioContext

Network

• Make the network module more attractive before std::asio or similar comes out (see also SFNUL)
• Make sf::Packet more flexible/generic
• Sending enumerations in sf::Packet
• IPv6
• HTTPS

35

SFML development / Info and Rules

« on: February 18, 2017, 12:26:05 pm »

Welcome to a new sub-forum!

SFML development's purpose is to provide a public space for discussions on SFML's development.

Back when the SFML Team was created, one of the criticism me and others had brought up were, that the development wasn't transparent enough. Over past few years, I think we've adjusted that significantly, with all changes to SFML happening in publicly available git branches, our CI system providing ready to use snapshots of every commit and having the recently introduced GitHub Project showing the status of the upcoming version more clearly.

With this sub-forum we want to involve the community even more in discussions in the past may have happened just internally and more importantly, with SFML 3 being on the distant horizon, we have to start with various discussions on what should or shouldn't be changed for the new major version. Additionally, the collection of threads should help us find and jump to specific discussions with easy, so we can prevent discussing the same topic multiple times.

In order to keep discussions concise, please read and understand the following rules and restrictions:

• This forum is meant for discussion on topics that are currently in development or planned to be developed soon.
• Only SFML Team members are allowed to create new threads.
• Everyone can post to created threads, but please stay on topic.
• The threads will be heavily moderated, so we can really focus on the topic.
• Feature requests still go into the dedicated sub-forum and have no place in SFML development.
  
• Suggestions for a topic to discuss next can be posted on the suggestion thread.
  
• Use a clear structure, like main point, arguments, use cases, examples.

See also:

• Suggestion Thread
  
• SFML's GitHub Project
  

36

General discussions / 2.4.2 released!

« on: February 11, 2017, 06:24:13 pm »

The long overdue second path version SFML 2.4.2 has been released!

The biggest changes are regarding context management again, where we fixed some pending issues.

The full list of bugfixes can be found in the changelog: http://www.sfml-dev.org/changelog.php#sfml-2.4.2

Visit http://www.sfml-dev.org/ for download instructions and extensive documentation. We hope this release is useful to you and would love to get some feedback in our forums!

37

SFML projects / One Room - 37th Ludum Dare Jam

« on: December 13, 2016, 01:28:54 am »

It's been quite a while since I last created a topic in this subforum!

I've taken part in the 37th installment of the Ludum Dare Jam.
The topic was "One Room" and after pretty much throwing away all the work from Saturday, I managed to finish a sort of point-and-click puzzle game.

Goal: Leave the room successfully.
Controls: Use the mouse to navigate and the keyboard to enter numbers and letters.

Submission <- RATE
Windows Binary [6.52 MB]
Source Code

It felt quite nice being able to just get into it and code again!

Enjoy, let me know what you think and don't forget to rate it over on the Ludum Dare site.

Here's also a list of all the blog posts I wrote during the jam:

• Let’s give this another go!
• Technology in use
• 6 Hours in and the progress is slow
• Change of plans
• One Room is finished (for now)!

38

General discussions / SFML 2.4.1 released

« on: November 04, 2016, 03:27:50 pm »

We finally got around to releasing a patch version SFML 2.4.1 that addresses a few urgent issues.

Some highlights are:

• Switched back to pure Xlib instead of XCB + Xlib
• This fixes quite a few issues for Linux (fullscreen bug, GNOME unresponsive issue, etc.)
• Removed the internal OpenGL context
• Which fixed the stack overflow on Windows when using multiple-threads

The full list of bugfixes can be found in the changelog: http://www.sfml-dev.org/changelog.php#sfml-2.4.1

Visit http://www.sfml-dev.org/ for download instructions and extensive documentation. We hope this release is useful to you and would love to get some feedback in our forums!

39

General discussions / SFML 2.4.0 released

« on: August 10, 2016, 11:41:41 am »

SFML 2.4.0

It's been nearly a year since the last patch release, so here we are again with a new SFML version!

Some highlights are:

• Added a deprecation macro and marked some functions as deprecated
  
• The mouse cursor can now be grabbed/locked inside a window
  
• SFML now supports geometry shaders
• As well as outlines for text
• A new API to set shader uniforms
• One can now record audio in stereo

And many more features and bugfixes of which you can find the full changelog including detailed descriptions here:
http://www.sfml-dev.org/changelog.php#sfml-2.4.0

Visit http://www.sfml-dev.org/ for download instructions and extensive documentation. We hope you enjoy this release and would love to get some feedback in our forums!

40

Feature requests / Use the -static flag when linking the C++ runtime static

« on: July 15, 2016, 02:10:18 pm »

More than 2.5 years ago I've already once made a pull request for this, but we decided to close it. However since this is still quite an annoyance of manually changing compiler flags whenever I build SFML (statically), I thought maybe it was worth addressing again.

Currently when you choose SFML_USE_STATIC_STD_LIBS in CMake, the CMake script will link libstdc++ and libgcc statically, so you won't have to provide these two DLLs. However, when you use a compiler that uses another runtime library it won't be linked statically and you'll have to provide the DLL as well. This is especially true with all the latest MinGW-w64 builds which use winpthreads for std::thread. What I've been doing for the past few years is adding -static to the C++ linker flags, which in turn will also link the winpthread library statically and I don't have to ship any DLLs. But every so often I forget to add it in the first place and thus have to build SFML again.

On the PR we had once the concern that -static would mean that the linker would try to link everything statically. I've never had any issues with it, as such I don't really see a disadvantage in using it, unless someone can point out some possible problem.

41

SFML wiki / Tutorial: Building SFML with a MinGW Compiler

« on: May 06, 2016, 10:29:00 am »

The other day I came across an older Stack Overflow answer (now updated) I once created on how to build SFML with a MinGW compiler. Eremiell suggested to put it on the wiki and so I did.

> Tutorial: Building SFML with a MinGW Compiler

Hope some will find it useful.

42

Audio / Crash in SoundFileWriterOgg::write

« on: March 04, 2016, 12:41:16 am »

If anyone is a bit bored and wants to investigate, I currently lack the time.

Windows 10
SFML master
Tested with: VS 2015, MinGW Builds GCC 5.3.0

Used code:

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

int main()
{
        sf::SoundBuffer buf;
        buf.loadFromFile("ff.ogg");

        std::vector<sf::Int16> samples(buf.getSampleCount());

        std::cout << "Memory allocated\n";

        for(std::size_t i = 0; i < buf.getSampleCount(); i++)
        {
                samples[i] = buf.getSamples()[i];
        }
        sf::SoundBuffer buff;

        buff.loadFromSamples(samples.data(), buf.getSampleCount(), buf.getChannelCount(), buf.getSampleRate());

        std::cout << "Loading new buffer.\n";
        buff.saveToFile("ff-test.ogg");
        std::cout << "Data written\n";
}
 

Call stack (from VS 2015):

        SupportVS.exe!_chkstk() Line 99
        SupportVS.exe!_vorbis_analysis_wrote()
        SupportVS.exe!sf::priv::SoundFileWriterOgg::write(const short * samples, unsigned __int64 count) Line 144
        SupportVS.exe!sf::OutputSoundFile::write(const short * samples, unsigned __int64 count) Line 76
        SupportVS.exe!sf::SoundBuffer::saveToFile(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & filename) Line 153
        SupportVS.exe!main() Line 22

Used sound file: ff.ogg [1.25 MiB]

Have fun debugging.

43

General discussions / Continuous Integration

« on: November 30, 2015, 12:17:15 pm »

The two CI pipeline help us tackle the following four challenges:

• Ensure that the code base builds successfully across all supported OS (Windows, Linux, macOS, Android, iOS)
• During development we often want people to test our branches, but it can be quite cumbersome for some to keep building SFML over and over again. By storing the artifacts of the builds we can provide up-to-date builds for each branch, including the master branch.
• Run our unit tests and in the future hopefully also our integration tests
• Detect problematic code with static code analyzers (Clang & Cppcheck)

Buildbot
Our custom CI pipeline is running with Buildbot and will automatically start build jobs whenever a branch on the SFML git repository is updated. For pull requests someone from the SFML Team will have to comment a trigger word in order to ensure that not random code is executed on the workers.

Buildbot: https://ci.sfml-dev.org/

There are four workers each having a different OS and doing multiple builds:

• Debian & Android & Static Analyzer
• Windows 10
• FreeBSD
• macOS & iOS

Additionally, we store all the build artifacts on the server. The list can be browsed either by branch or commit hash.

Artifacts: https://artifacts.sfml-dev.org/

Travis CI
For open source projects Travis CI is free, as such someone contributed a build file that also builds for all supported platforms and runs the existing unit test suite.
The big advantage here is that these builds run for every pull request, as they are executed on a containerized and secured system.
The artifacts from Travis CI are not stored as of right now

Travis CI: https://travis-ci.org/github/SFML/SFML

44

SFML projects / Surround Test

« on: November 18, 2015, 01:17:54 am »

The other day I got a new 5.1 surround system and whenever I want to test whether everything is setup right, I'm missing a nice tool to test all the speakers. Today I decided to write something. Introducing...

Surround Test

This is just the first iteration which allows you to pick the number of channels your system has (are there any systems with more than 8 channels?) and you can select a channel to play a sound from. Some channel counts are not supported and you'll just get an error message on the console.


Download

Windows [1.59 MiB]


Technical Bits

Unfortunately, there's no way with SFML to get the number of supported channels, nor is there a way to play a sound on one specific channel. This left me with the only option to give the channel count setting to the user and generating a sound buffer which plays the sound on only the selected channel.


Future

In addition to this simple surround test, I want to add another test, where one sound source is flying around the listener who is in the center. That way you can see how well the 3D effect is.
And the final goal is to have everything visualize a bit.
Ah yeah and GitHub code release will come one day as well.

45

Feature requests / Int32 overloads for sf::Time *, /, *= and /= operators

« on: November 11, 2015, 01:58:53 pm »

Someone on IRC has brought up that multiplying an Int32 with an sf::Time object results in a compiler error, since it's both, implicitly converting to float or Int64, are legal and thus the compiler can't decide and marks it as ambiguous.

So for example this code will produce a compiler error:

sf::Time a = sf::seconds(1.f);
sf::Time b = a * 2;

use of overloaded operator '*' is ambiguous (with operand types 'sf::Time' and 'int')

Since one can't mark operators as explicit, I think we should add overloads for Int32 as well.