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 - Ceylo

Pages: [1] 2

We need your help both for code review and testing.
The PR: https://github.com/SFML/SFML/pull/1418

New stuff

The following GUI based examples are updated and now added to the generated Xcode project if you set SFML_BUILD_EXAMPLES to true:
- OpenGL
- Window
- Pong

These are the ones that don't use shaders.
The current "iOS" example is removed as it doesn't cover more usages than the above examples.


The changes are mainly in CMake code, to fix linking and set a few required properties.
The examples C++ code also highlight a few behavior differences that we need to deal with: OpenGL vs OpenGL ES, different packaging of an iOS app, and mouse input vs touch input. If you see a more elegant way to deal with these, don't hesitate to tell!


Two aspects should be considered:
- you must be able to build & run the examples flawlessly from Xcode when targetting the simulator, same for a real device if you have a valid certificate from Apple. Note that there are still many issues with iOS implementation (aspect ratio when rotating, low-res display and graphical glitches), but these are out of scope in current PR.
- when performing an install of a desktop (not iOS!) build, the CMake files generated at PREFIX/lib/cmake/SFML must be identical with the ones generated by an install with current SFML master

Thanks for your time and feedbacks!



As you may know, Apple is pushing its own GPU technology, Metal, which was made available to iOS in 2014 and to macOS in 2015. In 2017 Metal 2 was released both to macOS and iOS.

On the other hand, macOS supports up to OpenGL 4.1 (spec released in 2010) and iOS supports up to OpenGL ES 3.0 (spec released in 2012).

On macOS, although OpenGL 4.2 (2011), OpenGL 4.3 (2012), OpenGL 4.4 (2013), OpenGL 4.5 (2014), OpenGL 4.6 (2017), Vulkan 1.0 (2016) specs have been published, they've been ignored by Apple.
On iOS, OpenGL ES 3.1 (2014) and OpenGL ES 3.2 (2015) are also not supported.


You can more or less see that since Metal was released in 2014, no progress has been made on OpenGL (ES) support. This is not an issue for short-term, except if you're targetting better performance. But the more SFML waits, and the more it'll sink in legacy (at least in mid-term regarding Apple platforms, and in long-term on other platforms too).

Potential solutions

Here are a few suggestions about what looks possible:
1. Have a platform-specific renderer : I don't know the amount of tweaks and the burden of current support for OpenGL (ES) in SFML on all current platforms, but having a renderer per platform is very likely to be an awful huge pile of work, both for development and maintenance.

2. Switch to OpenGL ES 2 on macOS through MoltenGL : this would potentially improve performance on macOS, and ease code sharing between macOS and iOS implementation, but on the other hand, OpenGL ES 2 is old (2007) and the fact that MoltenGL doesn't support more recent versions makes me think it will also die in a few years. Additionally it's not free (150$/user …) so… most likely not worth it.

3. Switch to Vulkan for all platforms : this is maybe a bit early but looks to be the most promising solution. According to https://en.wikipedia.org/wiki/Vulkan_(API)#Compatibility and a few other sources here is what's supported:

macOSmacOS 10.11+*macOS 10.11+*N/AN/AN/A

*through MoltenVK.

The worst case is Intel integrated GPU which requires at least a Skylake (6th gen) CPU.
On macOS and iOS, MoltenVK (which provides an implementation of Vulkan that is based on Metal) is open source and under the Apache 2 license.
Note that Metal support is related to the supported macOS/iOS version, not to a hardware, which is why I didn't put a year in macOS/iOS table cells.

Additionally LunarG provides a SDK for using Vulkan with validation layers, for all the platforms that SFML is using except Android which looks to have its own official Vulkan SDK.


Considering the points given above, to me the best solution looks to start relying on Vulkan, while still keeping OpenGL (ES) for now. That means supporting 2 (and a half if you count OpenGL ES) renderers for a transition period and giving up on OpenGL in ~2020, so that SFML can remain compatible with hardware from less than 5 years (the main issue being Intel GPUs). Considering that OpenGL is not immediately an issue the beginning of this transition can most likely wait one more year. Of course it depends on how long the SFML community is willing to maintain 2 renderers.

General discussions / How unified should desktop & mobile SFML be?
« on: April 08, 2018, 11:47:45 am »
(probably to be moved in SFML development section)

As far as SFML iOS and Android support is concerned, I wonder what is the wanted direction in terms of differences on a few aspects:
- examples

Currently it looks like there is zero difference on API side (the same API is visible on all platforms), although some APIs like TouchEvents and Sensors most likely only have a meaning on mobile platforms. And these APIs are implemented as empty stubs on desktop platforms from what I see.

Do we want the exact same API to be visible from both mobile and desktop? Or trigger a compilation error if a mobile API is used on desktop and vice versa? Or maybe we don't care yet because for now it's still rather obvious which APIs make sense in which context?

About examples, at the moment the Android example is totally disconnected from CMake stuff and is distinct from current GUI-based examples (opengl, pong, shader and window examples — although shader example is another story by itself ;D ).

For iOS there is also a distinct example which currently doesn't make use of any mobile specific API except a Touch event.

Regarding examples I would expect the following:
- current GUI-based examples (opengl, pong, and window) are adapted to work on mobile too, but share their code with desktop version
- examples that are here to showcase mobile APIs are kept distinct from desktop examples

This would most likely mean current iOS example would be merged or removed. As for the Android example, its main interest looks to be to showcase JNI usage (which then should not be optional in a #if defined(USE_JNI)), but I guess current GUI-based examples could also work for Android with small changes.

What are your thoughts?


I'm opening this topic because I feel like current PR submission process is not efficient and I believe this is discouraging people from contributing more (at least it discourages me).

To give a few numbers:
PRTesting & feedbacksWaiting to be merged
#13352 months2 days
#137112 days7 days
#13612 days10 days
#13343 weeks7 days
#1377~10 days*7 days*
#13952 days4 days
#13844 days3 days
#13562 weeks1 day
#13502 weeks0 day
#13452 days7 days
#13427 days7 days
* there was no feedback so not easy to tell if any testing phase happened and for how long

I hope this is representative enough. Of course I made this table mainly because I'm somewhat traumatized with the 2 months testing phase on my PR, that was mainly waiting and no feedback. But it's not the only PR in this case (at a smaller scale though).

There are several cases:
1. there are feedbacks and changes are required -> to me this is not an issue, so let's not focus on it
2. there are no feedbacks
  a. on (code) review -> should be improved
  b. on testing -> should be improved
3. PR is ready to be merged (code review, testing, feedbacks and CI are ok) but still waits to be merged -> should be improved

Of course I understand that the SFML core team can't do everything right away, and this is not what I wish. So here are a few ideas to help on these matters.

2.a : I don't know what are the current rules. Should the (code) review be done always by at least a SFML core team member, or can it be done by any member? In both cases my personal feeling is that currently the PRs that are blocked by a (code) review are not visible in SFML's PR list. The tags in https://github.com/SFML/SFML/pulls don't look to give this information.

To "fix" this we would need an easy way to see the list of PRs that are waiting for review. I can see 2 ways of doing that: a new tag on which you could filter on, on SFML's GitHub, or a forum section with a topic per PR needing review. This last solution looks maybe overkill but the advantage is that it's visible from all SFML forum members that would visit this section, and if people want to help on SFML development by reviewing, they can know where to help in an easy way. If we go this way it should be the PR's author's responsibility to open the topic in the forum section, so that it's not more burden for SFML core team.

2.b : Same questions about current requirements on testing. From what I saw it depends on whether the change looks "safe" or not. If it's safe testing is skipped, apart from CI. When testing is needed, can it be done by anyone or should there be at least 1 tester from SFML core team? Again this is very similar to 2.a. And we could most likely apply the same solution.

3. I noticed that only eXpl0it3r is merging the PRs. Why? I would expect that at least all members from the SFML core team could do this. Also I wonder if there is currently a minimal wait time before merge (I remember there were notices like "If nobody is against this PR withing X days it will get merged" in the past).

The goal would be for any PR that don't need updates (ie. only review and testing time) to be merged within at most 2 days. This is of course not doable if parts of the process can be done by too few people, but totally doable if the process is scalable.


General / FindSFML.cmake users, help test the new SFMLConfig.cmake
« on: February 10, 2018, 03:06:55 pm »
Hello :)

This topic is for users that already use the FindSFML.cmake script provided by SFML, or users that don't yet but would like to and whose project is also based on CMake.

What we would need from you

Since around 1 week ago the PR for supporting find_package(SFML) with a config file is ready for testing but we're still missing feedbacks at the moment. So if you can help on testing this means the pull request can be merged earlier. In particular, we'd appreciate if you tried it with your current workflow to know if any use case is missing. If everything goes well FindSFML.cmake will be removed from future releases.

What does SFMLConfig improve for me?

In terms of use, the SFMLConfig means:
- you don't need to embed FindSFML.cmake in your project anymore, everything is stored in the SFML installation directory
- you're not dealing with variables like SFML_LIBRARIES or SFML_DEPENDENCIES anymore, you just link your library or executable with sfml-${component} where ${component} is one of system, network, audio, window, graphics
- you don't need to use SFML_INCLUDE_DIR anymore to include SFML headers, it is done automatically
- when linking static SFML libraries, you don't need to use SFML_DEPENDENCIES anymore, it is done automatically
- again with static SFML libraries, you don't need to explicitly build with SFML_STATIC, it's done automatically
- you don't need to care about dependencies between SFML modules, for example if you link against sfml-graphics, sfml-system and sfml-window get automatically linked too
- like with FindSFML.cmake, you still don't need to care about whether you're building in Debug or Release mode, the appropriate SFML library is used automatically

How do I test this?

You need to clone the branch, build SFML and install it (build install target).

You should rebuild and install for all the configurations that you want to use (debug/release, dynamic/static/frameworks) to the same target installation directory. Then remove FindSFML.cmake from your project to make sure it's not used, and clear your CMake cache.

After that in terms of use it's just something like
find_package(SFML 2.4 COMPONENTS system window graphics REQUIRED)
target_link_libraries(my_exe PRIVATE sfml-graphics)
in your own CMake code.

Detailed doc for SFMLConfig

(click to show/hide)


General discussions / Why is SFML split with 1 dll file per module?
« on: January 04, 2018, 10:16:56 pm »

I’m wondering why each SFML module is represented by a distinct dynamic library file? Rather than a single SFML.dll.
I understand the semantic separation by related features, but this only requires separation by modules in documentation and in the API. When doing a new release, all modules are shipped together with the newer version, there is no independent versionning. Also all the modules account for less than 2.5MB so I see no need to sometimes ship only part of SFML for lighter distribution. This makes linking against SFML uselessly "complicated" (it’s quite simple already actually but could be simpler), and makes the project structure for SFML developers also more complicated than necessary.

So I’m wondering... why the split in several library files ?

General discussions / How is SFML going?
« on: December 23, 2017, 03:24:12 pm »

I've been following SFML for quite a long time (starting from the 1.4 era) where it was still developed by a few persons before going toward community development around SFML 2. Then I stopped following SFML around summer 2015.

Now I come back slowly to it and I wanted to know how it is going. I have seen a LOT (too much to read everything ;D) of discussions about future topics like SFML 3 and what should come next. But when looking at SFML Git history it looks rather calm, 3 to 10 commits per month. Like if these discussions had no conclusion. Or maybe everything is happening in forks before submission for PR. Or because SFML had fully matured, I don't really know.

So I'd like to hear the impressions from the SFML development community! How does it feel like to you? What are your ambitions for SFML's future?


General discussions / Why is SFML still using CMake 2.8 ?
« on: December 23, 2017, 03:09:31 pm »

I see that in the main CMakeLists.txt, SFML requires at least CMake 2.8.3. Which is now quite old : it is referenced as "Older Reference Documentation" when your look for its documentation, and was released 2 years ago.

The other reason I'm asking this is because CMake 3 provides a feature (and probably many others) that would be quite useful for all projects that use both CMake and SFML: interface libraries.
I have found one similar post from 2014 about it : cmake 3.0: Config-file Packages. But it's not available with FindSFML.cmake at the moment.

Basically this would mean one could write:
find_package(SFML 2 COMPONENTS network system)
target_link_library(MyExe PRIVATE sfml)
And that's all. Automatic handling of debug/release versions of SFML, not need to care about SFML_INCLUDE_DIR or SFML_DEPENDENCIES (static case would be written exactly the same).

So is it "just" a matter of doing it or there are other reasons?



In a project based on SFML I want to run tests on macOS using the provided frameworks. I don't want to install the frameworks, but instead set rpath correctly and put the frameworks next to my executable, so that I can check that I'm able to provide a fully self-contained package without depending on any installation.  Right now this means I need to copy these frameworks next to my executable:

My project is based on CMake and I want this to be automatic, so I use the provided FindSFML.cmake which provides these variables after doing a find_package(SFML):
SFML_LIBRARIES:    the list of all libraries corresponding to the required modules
SFML_FOUND:        true if all the required modules are found
SFML_INCLUDE_DIR:  the path where SFML headers are located (the directory containing the SFML/Config.hpp file)
SFML_DEPENDENCIES: the list of libraries SFML depends on, in case of static linking

However SFML_LIBRARIES only contains the direct dependencies (ie. the sfml-audio, sfml-graphics, sfml-network, sfml-system and sfml-window frameworks). So I could copy these next to my executable. But SFML_DEPENDENCIES is empty when using frameworks, most likely on purpose because it states that it's only for static linking. But then I don't know how I can get the path to the other frameworks just with a correct SFML_ROOT and find_package(SFML). Is it possible at the moment?

In the worst case I can probably hardcode the other paths but I would really like to avoid this if possible. This looks wrong and instead changes in FindSFML.cmake would probably be better.


SFML website / SFML 2.2 MinGW downloads clarification
« on: May 01, 2015, 03:00:57 pm »

Is it possible to clarify which MinGW distribution was used to build the "GCC 4.9.2 MinGW (DW2)" download?
Currently mingw.org only ships GCC 4.8.1 so this SFML download was obviously built with another distro.

This would help me because the library I'm making is built with the original MinGW and the produced binaries are not compatible with SFML's "MinGW" binaries.


Audio / Very simple sf::Music test crashes
« on: January 04, 2015, 09:00:22 pm »
On OS X 10.10, with both SFML 2.2 and Git head, running the following piece of code causes a Bus error:
int main()
        sf::Music music;

        if (! music.openFromFile("test.wav"))
                return 1;

        return 0;

The file "test.wav" does not exists, so failure is ok but it should not crash. LLDB backtrace is as follow:
Code: [Select]
* thread #1: tid = 0x1096d8, 0x00007fff951b3fcf libsystem_platform.dylib`OSSpinLockLock + 7, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x100000f74)
  * frame #0: 0x00007fff951b3fcf libsystem_platform.dylib`OSSpinLockLock + 7
    frame #1: 0x00007fff8b70477d libsystem_pthread.dylib`pthread_mutex_destroy + 25
    frame #2: 0x000000010001a497 sfml-system`sf::Mutex::~Mutex() + 23
    frame #3: 0x0000000100006b31 sfml-audio`sf::Music::~Music() + 65
    frame #4: 0x0000000100000dfb a.out`main + 347
    frame #5: 0x00007fff8da4c5c9 libdyld.dylib`start + 1
    frame #6: 0x00007fff8da4c5c9 libdyld.dylib`start + 1

Audio / sf::Music play() and pause() bug?
« on: December 25, 2014, 10:52:56 pm »

Just encountered an issue that I reproduced with this sample code:

#include <SFML/Audio.hpp>
#include <cassert>
#include "ResourcePath.hpp"

int main(int, char const**)
    sf::Music music;
    if (!music.openFromFile(resourcePath() + "nice_music.ogg")) {
        return EXIT_FAILURE;
    while (true)
        assert(music.getStatus() == sf::Music::Playing);    // (1)
        assert(music.getStatus() == sf::Music::Paused);     // (2)
        assert(music.getStatus() == sf::Music::Playing);    // (3)

    return EXIT_SUCCESS;

This code crashes most of the time on the assert (3), sometimes on the (2), and even some times on the (1) !!! I'm using the latest sources from Git (freshly built right now) on OS X 10.10.

I thought pause() and play() would be synchronous but… is this expected? ;D

Graphics / pimpl + sf::Transformable = ..?
« on: May 18, 2014, 09:41:40 pm »
Hello! :)

For the sfeMovie project I want to hide all implementation details to make the public API both cleaner and binary compatible for later additions.

To do so I've moved the implementation of the main class (Movie) into a pimpl (MovieImpl). Then each method of Movie forward calls to the pimpl. So far so good.

The issue is that the Movie class inherits from sf::Transformable and that one of my methods can modify the transformations (namely fitFrame()) of the Movie(Impl) object.

So here I can have transformations on 2 levels:
- on a Movie object, if the user uses one of setScale() / setPosition()
- on the MovieImpl object, through the fitFrame() call forwarded to the pimpl

I cannot forward calls for setPosition / setScale because these methods are not virtual. This is most probably a good point but here I get blocked. There can be transformations on 2 levels whereas I would like one transformation to overwrite the other and vis versa (just like several calls to setPosition() would do), and I would like to avoid putting the fitFrame() logic in the Movie class instead of MovieImpl…

Or maybe my class should rather inherit from a sf::Transformable subclass that defines this fitFrame() behaviour?

So this is mostly a design question and I wonder if anyone got into this issue :)

SFML projects / Mandelbrot Fractal Explorer
« on: September 08, 2012, 08:34:56 pm »
I would like to show a small project I've been working on for a fews days now.

It's a Mandelbrot fractal explorer. You can zoom in up to times and get precise rendering even at such scales (but at the cost of more rendering time). Move wherever you want, take screenshots and enjoy!

The explorer uses SFML to display the result, Thor to handle user commands and Intel TBB to parallelize work and accelerate rendering by using all of the available CPU cores (you may soon have a cooker integrated in your computer!).



If you want to give it a try on Windows:
- in case you don't already have Visual C++ 2010 installed, download the Visual C++ 2010 Redistributable Package and install it
- download the Fractal Explorer

And on OS X 10.7+:
- download the Fractal Explorer

You can have a look at the sources if you're interested but there's no easy way to build the program for now and there's been small modifications in the meantime. So it's mostly for curiosity purpose :) .

I hope you'll enjoy the exploration as much as I did!
Any feedback or comment is of course welcome :)

What is sfeMovie?

sfeMovie is a C++ library providing a central class that lets you play movies in SFML based applications. It relies on SFML for the rendering process and FFmpeg for the decoding process. It has been written to work closely with SFML and tries to keep the same easy-to-use paradigm, while remaining consistent with SFML's naming conventions.

Main features
  • allow reading and playing audio and video from movie files
  • provide basic controls like play, pause and seeking
  • support a lot of standard file formats and audio/video decoders
  • work on the main operating systems: Linux, OS X and Windows
  • give ability to display the movie within some frame while keeping the original ratio
  • provide access to the current image for external uses
  • support for stream selection
  • support for bitmap subtitles

Main supported decoders

Audio: AAC, AC3, FLAC, MP3, PCM, Vorbis, WMA
Video: H.264 (ie. MPEG-4 AVC), MPEG4, Theora, VP8, WMV

Other information

For the install steps, example code or downloads, see the sfeMovie website :)

2014 Septembre 26th: new website + forum, sfeMovie 2 binaries downloads, audio stream selection
2014 October 9th: ability to link against external or system FFmpeg binaries
2014 November 22nd: bitmap subtitles support
2014 November 23rd: binaries on the website with all the decoders
2014 November 30th: Added ability to create a static version of the sfeMovie library
2014 December 10th: Updated FFmpeg to version 2.4.3
2015 May 10th: Added seeking support
2015 May 24th: No more MinGW compiler needed on Windows, Visual C++ only.
2015 October 4th: Updated FFmpeg to version 2.8 + added ability to build for Visual Studio 2015
2016 January 2nd: Added optional support for textual (srt, ass/ssa, ...) subtitles
2016 January 2nd: Now providing Visual Studio 2015 binaries instead of Visual Studio 2013 binaries

Any feedback, be it good or not, is welcome!


Pages: [1] 2