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 4 ... 6
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)

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)

(click to show/hide)

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

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)

(click to show/hide)

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

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.

Quote from: 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
  • 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
  • Requires a study of language feature support on different compilers and compiler support on different platforms.

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

Suggested Topics
  • Unified way to handle cross-platform code
  • Different platforms (Windows Phone, Xbox, PS4, Web)
  • Unit testing
  • Error handling
  • General loading/saving facilities
  • 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
  • Aggregation instead of inheritance-based design
  • Investigate support for complex text layouts
  • Make CircleShape, RectangleShape, and ConvexShape only be shapes, not drawables
  • Single sound class with different resource backends (buffered or streamed)
  • sf::AudioContext
  • 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

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:

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!

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:

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!

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:
And many more features and bugfixes of which you can find the full changelog including detailed descriptions here:

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!

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.

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. ;)

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;

        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";
        std::cout << "Data written\n";

Call stack (from VS 2015):
        SupportVS.exe!_chkstk() Line 99
        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. ;)

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)

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:

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

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.


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.


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. ;)

Pages: 1 [2] 3 4 ... 6