Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - eXpl0it3r

Pages: [1] 2 3 ... 6
SFML development / Removing dependency binaries
« on: January 26, 2019, 06:56:57 pm »
Some years ago the SFML Team had decided to remove the binaries of SFML's dependencies from the git repository. Reasons for the removal range from bad practice to bloating the size of the repository, but there were also concerns raised about usability of SFML on Windows.
The decision back then was to move the binaries into a dedicated repository and add that as sub-module. Unfortunately as you all know, that decision was never implemented.

Now, when we look ahead a bit and see how SFML may evolve in the near future, there are chances that more dependencies will be introduced (harfbuzz, Opus, MP3, ...), more platforms will be supported in one way or the other and it becomes pretty clear, that the current setup doesn't really scale well.

Having to provide binaries for all the dependencies and all the platforms that need it and keeping them updated, is a time consuming task. We also end up making trade-offs for small file size, to not further bloat the repository size. As such, the idea came up to propose yet another approach.

Remove the binaries from the git repository, but instead include the source code of said dependencies and instrument our CMake build system to build the dependencies when building SFML itself.
This has the advantage that we cut down the size of the repo, remove the binary building maintenance cost on our side, can add more dependencies without mentioned concerns and if people want to, they can more easily modify or update the dependencies for their own needs.

Notice, the goal isn't necessarily to add sub-modules or let CMake dynamically fetch stuff, but instead provide everything that's needed to build SFML and its dependencies, but we'd like to hear your ideas on that topic as well. As an example take a look at Qt's setup.

What are your opinions on this topic and are there any takers for implementing the CMake scripts changes? :)

General discussions / What pain points do you experience using SFML?
« on: January 07, 2019, 10:23:42 am »
Some of you may have already seen or even replied to, a week ago, we asked people on Twitter and Reddit what their pain points are or were when using SFML.


We started on Twitter and Reddit in hopes of catching those developers who aren't regularly visiting the forum, but since we're interested in collecting as much feedback as possible, we also want to ask everyone here.

What are/were the pain points you experience(d) while using SFML?

General discussions / SFML featured in...
« on: December 10, 2018, 11:36:52 am »
As SFML has started to pop up here and there in different formats or places, I've decided to change the existing thread into a pinned thread, where we can post new things without having to create new threads every time. :)

Please post new-ish things SFML has been featured in!

Jonny just pointed out on Discord that Microsoft used SFML's Pong example in one of their Visual Studio 2019 Preview video to show off their cross-platform development features and more.

Thought some of you might find that interesting as well. :D


General discussions / SFML 2.5.1 released
« on: October 18, 2018, 11:44:09 pm »
SFML 2.5.1

A bit longer than expected, but here's the new SFML version! :)

This is a patch version release and thus only contains bugfixes.
  • After the big sf::RenderTexture refactor in 2.5.0 there were a few bugs which got fixed in this version
  • Linux saw some long await fullscreen/multi-monitor fixes
  • As well as a critical bug in the new clipboard API
And a few other fixes. The full changelog including detailed descriptions here:

We're very grateful for everyone contributing, testing and discussing!

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

SFML development / SFML Roadmap
« on: August 22, 2018, 04:52:22 pm »
I'd like to discuss the next few steps for SFML's development. I've worded it as if things are already decided, but in fact it's all up for discussion.

Let's start with the big elephant in the room: SFML 3

The bad news: It's impossible to integrate all the changes we have promised, discussed or wished for over the past years.
The amount of potential API changes and redesigns is too great to fit into one version of SFML.

The good news: It has become clearer over the past few years, that a lot of people have adapted the "new" C++ standards and are looking for APIs that do support modern C++ (e.g. move-semantics), but also don't feel particual motivated to contribute to "old" C++ code bases like SFML.

SFML 3 will first and foremost focus on introducing the C++17 standard to the SFML code base and to get rid of some baggage.
Additional API changes or redesigns have second priority on the list.

The overall goal is to accept that major version updates don't require massive library evolutions on the scale of barely achievable, but that breaking changes should be able to happen more frequently and within a manageable scope.
This also implies that we'll actively try to avoid dragging a major version on for many years, which has the the effect, that SFML 3 will end up rather short-lived compared to SFML 2.

Here's a rough roadmap what the goal is in the near future:

SFML 2.6 (see GitHub Project for details)
  • Scan codes
  • Required bug fixes
  • Small championed contributions


Priority 1

Priority 2
  • Hot API discussion points (TBD)
  • (Setup for multiple rendering backends)


We're generally open to backporting critical bug fixes to SFML 2, but it will be decided on a case-by-case basis and the focus should really be in moving forward.


The current roadmap moves SFML 3 from an infinitely far away horizon to the next version after SFML 2.6. Major versions don't require massive API evolutions, but it simply indicates a breaking change.

I'm interested in hearing what people think of this proposal, so let the discussion begin!
Keep in mind though, that the point of the discussion here, isn't necessarily about a single item on the list, but it should be more on the whole perspective change.

SFML development / SFML Test Strategy
« on: August 15, 2018, 11:15:40 pm »
It's no secret that automated tests have many benefits and after many years of discussions and one stale git branch, it's time to finally dive in.

There are many different kinds of automated tests. We will limit ourselves to Unit Tests and Integration Tests for now. The following should give a brief overview of what kinds test we expect and how to approach testing.

Unit Tests

Unit tests should only test one specific unit independently from any other unit as much as possible. This means that we're not testing what effect one unit has on another unit, but simply check the functionality of that one unit.
For SFML a unit is most of the time simply a class. For example sf::Rect<T> is a unit, sf::Vector2<T> is a unit, but the unit tests for sf::Rect<T> shouldn't check that the properties of sf::Vector2<T> are set correctly, because the sf::Rect<T> unit tests, should only test the sf::Rect<T> interface.
The point is, if every class has its own unit tests, we can be certain that every class behaves exactly the way we expect them to, so they don't need to be retested.

The foundation for unit tests should be introduced with SFML 2.6.0.

Integration Tests

Integration tests on the other hand do intentionally connect multiple units to ensure that in combination they behave as expected.
For SFML this can often mean, that we let one unit pass through other units and finally transform the result into a format that can be asserted. For example the rendering of a shape would go through a render texture and then convert to an image, which can be compared pixel by pixel with a test data image.

The proper setup and intent of integration tests still needs to be determined, but some things will certainly build on top of the unit test setup.

What do we test?

Tests exist to assert that the promises we make by providing a public API, actually hold true.
As such unit as well as integration tests should only ever test the public interface and ensure that the API does what the documentation says.

When do we write tests?

For every new feature there should be multiple new unit tests, testing positive as well as negative test cases.
For every bugfix there should be at least one new integration test, that covers the bug and ensures that there's no regression.

DotNet / Drop .NET Framework in favor of .NET Core?
« on: August 14, 2018, 11:18:46 am »
SFML.NET has been slightly abandoned in the last few months and I'd like to change that with everyone's help. :)

One of the first things we need to do, is decide what direction SFML.NET should take.

  • Do we want to keep supporting .NET Framework?
  • What are the advantages of keeping support for the .NET Framework?
  • Are we going to support .NET Core only?
  • Are we supporting .NET Core 2 or also any other version?
  • What are the advantages of .NET Core 2?

I think, we did answer some questions already, but let's try to collect all the arguments here and then have one place to "document" the decision here.

General / SFML 2.5 CMake Migration
« on: May 23, 2018, 12:18:16 am »
With SFML 2.5.0 we have modernized our CMake build system largely thanks for Ceylo! :)
In the last weeks however we've noticed a considered amount of people not realizing the changes and thus wondering what to do with their "broken" build system. This thread should help clarify the required changes to utilize the new SFMLConfig.cmake file.

FindSFML.cmake has been removed
You can look for it as long as you want, it doesn't exist anymore, regardless of guide XYZ said, if you use SFML 2.5.0 there's no FindSFML.cmake anymore.

This also means, you no longer have to make sure that FindSFML.cmake can be found in CMAKE_MODULE_PATH. As such if you have some code like SET(CMAKE_MODULE_PATH ...) you can remove that from your CMake file.

SFML_ROOT is no more
Windows users (and maybe others) have gotten used to setting SFML_ROOT in order to tell the FindSFML.cmake where to look for SFML. This isn't true anymore and instead the error message with suggestion CMake throws at you, can finally be implemented.

Could not find a package configuration file provided by "SFML" (requested version 2.5) with any of the following names:


Add the installation prefix of "SFML" to CMAKE_PREFIX_PATH or set "SFML_DIR" to a directory containing one of the above files.  If "SFML" provides a separate development package or SDK, be sure it has been installed.

Meaning, if the SFMLConfig.cmake file can't be automatically located, you can provide the directory containing said file by setting SFML_DIR.

This is now mostly automated. The include directory no longer needs to be manually set, so this step can be completely removed. As for the libraries, all you need to specify is the dependencies on the highest level in a dependency tree. Meaning, if you want sfml-graphics, you only need to search for the graphics module and link the sfml-graphics library, CMake will take care of resolving the additionally dependencies like sfml-window or sfml-system. Even for static libraries, you don't need to specify the dependencies as CMake will do it for your.

Example CMake script
Here's an example script that links sfml-graphics and sfml-audio and their dependencies.

cmake_minimum_required(VERSION 3.1)


## If you want to link SFML statically

## In most cases better set in the CMake cache
# set(SFML_DIR "<sfml root prefix>/lib/cmake/SFML")

find_package(SFML 2.5 COMPONENTS graphics audio REQUIRED)
add_executable(SFMLTest main.cpp)
target_link_libraries(SFMLTest sfml-graphics sfml-audio)

A more detailed usage documentation can be found directly inside the SFMLConfig.cmake file.

While you're here, you might as well try to get your project updated to modern CMake. This article might be useful for you. ;)

General discussions / SFML 2.5.0 released
« on: May 09, 2018, 11:59:11 pm »
SFML 2.5.0

We're finally here with a new SFML version! :)

Here are some highlights we're excited to share with an official release.
  • Modern CMake support with SFMLConfig.cmake
  • New system cursor API
  • New clipboard API
  • Introduction of sf::VertexBuffer
  • Added loop points for sf::Music
And many more features and bugfixes for which you can find the full changelog including detailed descriptions here:

We're very grateful for everyone contributing, testing and discussing!

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

General discussions / Discord server
« on: April 19, 2018, 10:33:45 pm »
While we all love and welcome people to IRC, times have changed and requests have been made to provide access to a more modern chat application. Discord has found a lot of popularity in recent years and offers a lot of options beyond just text chat.

With our Discord-IRC bridge we also try to not split the community, but to connect everyone. Come join us by clicking on the Discord logo below! :)

SFML website / Website downtimes in recent days
« on: March 08, 2018, 10:42:27 am »
Some of you have noticed that we had a long down time last night and had a few down times yesterday and last week. The root cause of it is unclear.

The long downtime last night was to replace the server hardware except the storage devices, as such we're hoping that the server will be running stable again.

Sorry for any inconveniences cause by this.

In case of any incidents I try to keep people up to date via @sfmldev on Twitter.

C / Shouldn't CSFML use CSFML as include directory?
« on: September 11, 2017, 08:10:45 pm »
Currently CSFML uses "SFML" as include directory. Which means, when you install SFML and CSFML the two include directories get mixed into each other.

Since they both use different header extensions it's not really an issue, but I feel it's not a very clean solution.

Wouldn't using "CSFML" make more sense?

SFML development / Current focus: SFML 2.5.1 Release
« on: September 07, 2017, 01:23:04 am »
In an effort to push development a bit more, we want to start focusing our efforts on one specific issue or feature at a time.
This thread serves as an announcement thread, so don't forget to add the thread to your watch list!

Current focus: SFML 2.5.1 Release

Progress tracking:

Needs testing:

Check the GitHub Project to see current progress!

(click to show/hide)
(click to show/hide)


While the SFML forum provides a section for projects, it happens too often that nice projects get lost in the depth of that sub-forum or that the archive with the game executable or source code gets deleted overtime. With the SFML Projects website we want to provide a platform to host, share and archive projects that were made with or for SFML.

  • SFML Projects is open source and hosted on GitHub. If people are eager to help out, I'll gladly add them as contributors!
  • In the very near future, I'll allow others to directly add and edit projects via the administration panel.



Seeing how really neat SFML games got forgotten and often their download links died as well, I had the idea to create a platform to share and archive SFML projects.
I made multiple attempts at creating a website that was simple to use, yet easy to manage. Switching from one CMS to the next framework, it never really clicked and development was slow and thus demotivating.
But recently I've been working with yet another CMS and noticed how easy it was to create a simple custom administration interface, plus utilizing some template to handle adding new projects easily.
Using the existing design, I was able to build a functioning and easily extensible site within just a few days!
It's not feature-complete yet as it currently is just a simple list of games and libraries, however with this base, it's relatively easy to create more detailed project pages.
A special thank goes to achpile and zsbzsb for having helped me out on previous versions in various ways!

SFML development / sf::NonCopyable and =delete
« on: April 04, 2017, 02:48:34 pm »
Info & Rules about this sub-forum

(Originally posted on the C++ standards thread.)

C++03 didn't offer a way to tell the compiler that a class wasn't meant to be copied, but in order to trick the compiler into preventing exactly that, one could make the copy-constructor and assignment-operator private.
sf::NonCopyable used that trick and by acting as an abstract base class (interface), all classes that should be non-copyable could simple derive from it.

The question would be:
  • Should we keep sf::NonCopyable and just change its implementation to use C++11 = delete?
  • Or should we remove the class and use the native C++11 language feature = delete?
In binary1248's latest C++11 refactoring, he's removed the class, in case you want to see how such a change would look like.

Personally, I find that sf::NonCopyable only existed to trick the compiler for a missing language feature. With C++ we got that feature through = delete, so I don't really see the reason to keep it.

Error messages will change, but people who are used to C++11, should understand the error message of C++11 better than a more cryptic error in combination with sf::NonCopyable.

Pages: [1] 2 3 ... 6