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
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 / Visual Studio 2019 Preview with SFML
« on: December 10, 2018, 11:36:52 am »
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 is that SFML 3 won't be what we have hyped it to be for past years. Simply put, it won't be a refactoring of everything.
The good news is, that cutting down on "change everything" actually brings SFML 3 into a scope again, that can be achieved.

SFML 3 will first and foremost focus on introducing the C++14 standard to the SFML codebase and to get rid of some baggage. Only secondarily will we evaluate API changes.

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 again means, 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)

  • C++14
    • Move semantics
    • NonCopyable
    • unique_ptr
    • ...
  • Deprecation
  • Hot API discussion points (TBD)
  • (Setup for backends)


This shouldn't be at the center of the discussion, but as the question my arise, I just want to mention it now. We're open to backporting certain bugfixes to SFML 2, but we're also reserving us the rights to decide whether it makes sense or not.


The current roadmap moves SFML 3 from an infinitely far away horizion 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.

SFML development / Clipboard Support
« on: March 21, 2017, 03:58:13 pm »
Info & Rules about this sub-forum

Note: Just to prevent potential confusion, this subforum is not just dedicated to SFML 3 discussions, but it's open to any SFML development topics like the this one right here.

Clipboard support has been a long requested feature (thread #1, thread #2) for many obvious reasons. In the past we had one attempt (forum post, pull request) at getting it implemented, but the discussion dragged on for a while and after the API discussion was mostly finished, nobody took it up and actually implemented the suggestion, until now...

In the past few weeks Ricardo (aka Ricky) has been working on a new implementation: https://github.com/SFML/SFML/pull/1204
His implementation seems to mostly resemble what had been discussed and is up to date with SFML's code base (switch back to Xlib).
While this thread can be considered a continuation of Aster's thread, I think starting fresh makes more time. I will try to summarize previous discussions.

I also like to mainly focus on the implementation bits and less about how the functions should be named, as this is a minor detail and will easily distract from the important discussion points.

Proposed API
// Get the content of the clipboard as string data
sf::String str = sf::Clipboard::getString();
// Set the content of the clipboard as string data
sf::Clipboard::setString(const sf::String& str);

  • Linux (X11) requires access to a window's event processing and thus requires the use of a window.
  • Windows claims in MSDN to require a window handle to set the clipboard content, but in practice it seems to also work with a handle of NULL. For comparison, SDL and GLFW provide a window handle.
  • OS X and iOS don't require a window at all.
  • Android doesn't seem to require a window either.

Previous Decisions
  • The clipboard should not be part of the sf::Window API, but it's own class.
  • The use of a window is an implementation detail and should not be reflected in the public API.

Current implementation
  • For Linux, the implementation uses a dedicated, hidden and lazy-loaded window with its own busy-waiting thread to handle the events.
  • For Windows, there's no window handle used, instead NULL is passed to OpenClipboard.

  • Is the Linux implementation acceptable for us?
  • For Linux, should we instead try to use the global vector of windows that already exist in the window class? And how do we get access to the event processing of the given window?
  • For Windows, there's currently no window handle used, should the implementation be adapted to use a window handle? And how should the clipboard class get access to an active window handle?
  • For Linux and Windows, what should happen if there's no active window available?

Example code
(click to show/hide)

Pages: [1] 2 3 ... 6