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.

Messages - Ceylo

Pages: [1] 2 3 ... 69
Graphics / Re: FFMpeg and SFML
« on: June 01, 2020, 10:14:20 am »
1>/usr/bin/bash: riga 0: cd: too parameters /arguments
This one I don't know, and as I'm not maintaining sfeMovie anymore, you'll need to figure out by yourself. The only idea that comes to my mind right now is to try to avoid spaces in your sources path and build path. But it is one of the most important error here and is the consequence of almost all other logs.

3>------ Start building: Project: sfeMovieDemo, Configuration: Debug Win32 ------
4>------ Start building: Project: sfeMovieMinimalistDemo, Configuration: Debug Win32 ------
4>C:\Users\pc\Documents\Visual Studio 2017\Projects\sfeMovieLaTest\examples\MinimalistDemo\main.cpp(26): fatal error C1083: It's not possible to open include file: 'SFML/Config.hpp': No such file or directory
3>C:\Users\pc\Documents\Visual Studio 2017\Projects\sfeMovieLaTest\examples\Demo\main.cpp(26): fatal error C1083: It's not possible to open include file: 'SFML/Config.hpp': No such file or directory
4>Compilazione progetto "sfeMovieMinimalistDemo.vcxproj" NOT COMPLETED.
3>C:\Users\pc\Documents\Visual Studio 2017\Projects\sfeMovieLaTest\include\sfeMovie/Movie.hpp(29): fatal error C1083: It's not possible to open include file: 'SFML/Graphics.hpp': No such file or directory
3>C:\Users\pc\Documents\Visual Studio 2017\Projects\sfeMovieLaTest\include\sfeMovie/Movie.hpp(29): fatal error C1083: It's not possible to open include file: 'SFML/Graphics.hpp': No such file or directory
3>c:\users\pc\documents\visual studio 2017\projects\sfemovielatest\examples\demo\UserInterface.hpp(29): fatal error C1083: It's not possible to open include file: 'SFML/Graphics/RenderWindow.hpp': No such file or directory
3>Generating code...
3>Project building "sfeMovieDemo.vcxproj" NOT COMPLETED.
These are also related to CMake update with SFML 2.5, but are just the examples, not the library itself. If you want to fix them, update their CMakeLists.txt in target_link_library() call to link against sfml-graphics and sfml-audio.

Graphics / Re: FFMpeg and SFML
« on: May 31, 2020, 08:17:28 pm »
The prebuilt binaries at https://www.sfml-dev.org/download/sfml/2.5.1/ contain said SFMLConfig.cmake
As for helping CMake find it:
if the SFMLConfig.cmake file can't be automatically located, you can provide the directory containing said file by setting SFML_DIR

Graphics / Re: FFMpeg and SFML
« on: May 31, 2020, 04:15:51 pm »

The changes suggested by eXpl0it3r should be appropriate (in addition to removing FindSFML.cmake from sfeMovie sources as you noted). Indeed sfeMovie was created before FindSFML.cmake was removed from CMake.

Seeing your last CMake screenshot, it looks like you still have input from a previous CMake session. I'd recommend that you delete the CMake cache from sfeMovie build directory and configure again in CMake. SFML_DIR entry is not supposed to appear again in CMake window.

I may try to push it upstream, but since it kind of makes sfeMovie only support SFML 2.5 and higher...
You know that I am rather fine with breaking compatibility with previous versions :) Especially if it means that it'll work out of the box with the latest SFML version. However I don't wish to spend time on sfeMovie at all, and merging PRs requires at least a bit of testing, so the best would likely to make this change in your own fork.

Why do you want it to be in a sprite?


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!

Window / Re: iOS incorrect window size on reorientation
« on: April 12, 2018, 08:16:57 pm »
Really nice that you've found the culprit!

For 1) in terms on API I don't see any reasonable solution apart from replacing the Style::Resize enum value with Style::Rotate or similar when compiling for mobile. By the way Style::Close also looks to make no sense on mobile.

For 2), I'd also go for keeping the same behavior as the OS. It doesn't make sense to have no orientation supported.

General / Re: [iOS] SFMLConfigDependencies.cmake looks for OpenGL
« on: April 11, 2018, 09:23:49 pm »
Indeed, the fact that you had to manually set the dependencies clearly shows that it wasn't supported.

To give some insight, the SFML config file is generated automatically according to targets to be exported. For desktop platforms the call to sfml_find_package(OpenGL ...) in src/SFML/Window/CMakeLists.txt creates this OpenGL target and flags it to be exported. But in iOS case sfml_find_package(OpenGL ...) is not called. Thus no OpenGL target gets exported. Thus you get an CMake error telling that the OpenGL target doesn't exist. There are probably quite a few changes to bring to current CMake code because there is no need to search for any OpenGL package on iOS, as usually you directly link using "-framework OpenGLES".

Those changes will probably arrive soon as they are also needed to get all GUI examples running on iOS.

SFML projects / Re: FM Composer - A sound & music creation tool
« on: April 10, 2018, 12:17:09 am »
Dunno how to tell and I a newbie in music composition/generation but… it just looks (and sounds) awesome!

First of all congrats for the huge work! (and then good luck for the bugfixes :D )

I've tested on macOS with a french mac keyboard, exactly this layout:

Will give the results line by line, starting from the top of the keyboard:
First line:
(click to show/hide)

Second line:
(click to show/hide)

Line 3:
(click to show/hide)

Line 4:
(click to show/hide)

Line 5:
(click to show/hide)

Line 6:
(click to show/hide)

Additionally (but maybe out of scope), I found a few buggy combinations:
1. Holding left ctrl + right ctrl prevents right shift from being detected, and also prevents usage of all keys of 2nd line up to ScanEquals, as well as numpad keys 4, 5, 6 and +
2. Holding left alt + right alt prevents usage from all letter keys in 4th keyboard line, as well as numpad 7, 8, 9 and - keys

Note that both (1) and (2) don't not look to be specific to SFML, TextEdit app provided by Apple does the same weird thing.

The question is not if... but how and when.

I would have already started with this years ago if it were not for this unresolved discussion.
I understand this is part of the problem, but only a (big?) part. Anyway will check this topic :)

And what about using SFML as an OpenGL window API?
Unless I miss something there is no question on this matter: if the user chooses the OpenGL backend he can use OpenGL, otherwise he can't. If/when OpenGL support is dropped, then SFML can't be used as an OpenGL window API anymore, but at that time OpenGL will most likely be obsolete.

The fact that you can use SFML as an OpenGL capable window isn't going to disappear.
It should! At least once Vulkan is widely enough supported. You don't want to maintain 2 backends forever.

General discussions / Re: How unified should desktop & mobile SFML be?
« on: April 08, 2018, 10:55:18 pm »
I don't think so. The difference between "mobile" and "desktop" tends to disappear, both on hardware side (laptops which are tablets + keyboards) and on OS side (almost all OS try to unify their mobile and desktop version).

I think a Windows version of the Touch API is pending in PRs, and we could as well make a Linux version of it.
Ok we'll see how it goes on. Even if both tend to be closer, most of the time in desktop PC you have much fewer sensors. But I guess there is no actual limitation so it's not worth forbidding its use on desktop.

Another example I can think of is the sf::Window size. Fix me if I'm wrong but to me it doesn't make sense to use anything else that the full screen size on mobile, or at least the size that the OS tells you you can use. In that sense, sf::Window constructor should probably have no size param at all when compiling for mobile.

Do we want the exact same API to be visible from both mobile and desktop?
It's hard to say, I guess we should invest some time to list the APIs which belong to only one of these two worlds, in order to get the full picture and then make a decision.
Ok, we'll see over time, unless someone has a clear vision already. On my side I still need to get familiar again with the whole Window module.

I know nothing about Android stuff, but what's preventing these examples from working on iOS directly? As far as I remember:
- several years ago when I started to port SFML on iOS, I managed to make some examples work
- there's now a clean CMake toolchain for iOS

Listing the problems (either blocking or not) to compile iOS (and Android?) examples with the same setup as on desktop OSes, would be a good starting point I think.
I know nothing about Android too :D (maybe Mario can help?)
As for iOS :
- the CMake MACOSX_BUNDLE property must be set on target
- the CMake MACOSX_BUNDLE_GUI_IDENTIFIER property must be set on target (otherwise launching in simulator makes Xcode crash :-° )
- need to include <SFML/Main.hpp>
- need a few tweaks related to OpenGL ES (glClearDepth -> glClearDepthf and glFrustum -> glFrustumf)
- need to embed their media resources

So nothing big. Which I guess means we don't need to have mobile-only version of current GUI-based examples.



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?

General / Re: [iOS] SFMLConfigDependencies.cmake looks for OpenGL
« on: April 08, 2018, 11:05:51 am »
Hello texus,

SFMLConfig.cmake indeed doesn't support iOS for now (like previous FindSFML.cmake). Feel free to open a PR if you want to add this support.

I've already spent multiple hours writing my original response
And you may save weeks of delays :) Thank you for opening the section and I hope it'll prove useful.

and honestly, I rather invest my time into other things, than having everything I wrote being slammed down and things I suggest as improvements not being discussed at all.
Well as you didn't look convinced on the "why", it's expected that there were not many answers on your "how". I didn't mean to ignore your efforts in any way.

If anyone feels like the sub-forum needs a bit more explanation feel free to create a thread and I'll sticky it. :)
Right now I would suggest small additions to current Contribution Guidelines to make is somewhat become a habbit:
- at the end of "Testing" section: Additionally, you can check the dedicated sub-forum for pull requests that need help on testing.
- in "Sending patches/pull requests" section, as bullet point 4: In order to get faster feedbacks on review and testing, feel free to open a topic in the dedicated sub-forum and communicate on what help is needed.

Additionally, I've started a PR for Issue and PR templates. I think they can still be improved, but I'm also highly interested in what others would put there. So please head over to GitHub and make some suggestions.
Nice! Seems like a nice lowcost addition.

Hiura suggested to create a GitHub Project at the organization level. As it is right now, I don't really see a huge benefit to it - the only difference is that we now have some website tasks there as well - and as down side, it could be less discovorable. The main SFML repo will be the entrypoint to SFML on GitHub for most and very few will navigate to the organization level to find the GitHub project there.
I agree about SFML repo being the main entry point so I don't think it's needed.

Pages: [1] 2 3 ... 69