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] 4 5 ... 69
31
SFML development / Re: iOS development progress
« on: February 17, 2018, 03:39:23 pm »
I've removed ARM 32 bits support, added an option to choose the iOS deployment target and made sure iOS static libs are found first, even if "matching" frameworks are installed in /Library/Frameworks.
Changes are still visible at https://github.com/Ceylo/SFML/compare/feature/CMakeTargetExport...Ceylo:feature/iOSCompilation

Also the crashes when launching examples in the simulator look to be related to code signing / bundle identifier. After setting them and doing clean/rebuild it launches correctly in simulator.

For now I could launch both the "window" and "opengl" example in simulator and real iOS device, but the display remains full black without any errors in logs. And pausing the app shows a normal running event loop.

Also I couldn't build the pong example because the freetype static lib wasn't built with bitcode enabled. I guess there'll be the same issue with the flac, ogg and vorbis static libs. According to Apple documentation, bitcode is optional when building for iOS, but is required for tvOS and watchOS. Also even for iOS it is enabled by default, so it feels like it will be much simpler if we stick with their default. I have no idea how iOS dependencies were previously built though. If we go with rebuilding them, we should also take this occasion to lower the iOS deployment target (currently 10.2) as I don't see any reason not to support iOS 9 for example.


Edit: I fixed CMake code to always the bundle identifier on examples so no more IDE crash. Also did half of the work for code signing to ease building for real devices. I say half because Xcode looks to automate some parts when a developer chooses a "Development Team" and I don't know how to do that with CMake.

32
SFML development / Re: iOS development progress
« on: February 17, 2018, 11:57:31 am »
Good to know that 32 bits support can be dropped! That's what I thought but wasn't sure. From what I saw this excludes iPhone 5C (released in 2013) and older. Should be quite ok. Also found this grid which provides a nice overview: http://blakespot.com/ios_device_specifications_grid.html

So will drop armv7 support and probably let the user choose the deployment target. I noticed however that the externals static libs for iOS were built with iOS 10.2 as min target. So unless we recompile these we'll probably have to stick with 10.2 as a minimal requirement for now.

33
General / Re: Image of Sprite Skipping on Screen
« on: February 17, 2018, 11:47:24 am »
Did try to run your example but I miss "tileable_space.jpg", can you provide it?

34
General / Re: FindSFML.cmake users, help test the new SFMLConfig.cmake
« on: February 16, 2018, 08:05:09 pm »
Hello,
We still need people to test! Please help if you can.

Thanks,
Ceylo

35
SFML development / Re: iOS development progress
« on: February 12, 2018, 10:33:57 pm »
Hello,

I've tried again to build SFML for iOS but to me it looks like there are so many issues at the moment. Just to have it compile :(
- First when targeting a real device, it tries to compile for armv7 but emit compilation errors because it also targets the latest iOS for deployment target (iOS 11) which doesn't support armv7 (this is 32-bits arm). So I made change to have iOS 10 as deployment target for now.
- Then although the toolchain file sets CMAKE_OSX_ARCHITECTURES correctly, this is set when project(SFML) is called in main CMakeLists.txt, but at that time CMAKE_OSX_ARCHITECTURES is already set to x86_64. And by default CMake doesn't change already set cache entries. So you get a x86_64 build for your iOS device :D (have fixed that on my side too)
- Also I don't understand why find_host_package() is used to find dependencies, because from what I understand this means finding dependencies for the host platform, not the target platform. But when you build for an iOS device you need to build with dependencies made for the target platform. On the other side I can't get anything to work with find_package() so I guess find_host_package() exists for a reason ;D
- find_host_package() finds frameworks in /Library/Frameworks if I don't remove the vorbis, ogg and FLAC frameworks there, instead of choosing the static libraries from SFML's extlibs dir.

Apart from that it builds ;D

Edit: i've put my changes there for now: https://github.com/Ceylo/SFML/compare/feature/CMakeTargetExport...Ceylo:feature/iOSCompilation
Could get all examples to build (with a few tweaks related to OpenGL vs OpenGL ES) not comitted yet as it's WIP. It's based on my other branch because eventually it's easier to setup everything and propagates properties correctly.

36
General / Re: FindSFML.cmake users, help test the new SFMLConfig.cmake
« on: February 11, 2018, 02:12:18 pm »
Quote from: Ceylo on February 10, 2018, 11:08:57 pm
It's most likely possible to deduce that if the user asked for "graphics" component then we should also consider "window" and "system" to be among the requested components. Will fix that.
Done. So now we can do
Code: [Select]
find_package(SFML COMPONENTS graphics REQUIRED)
target_link_libraries(my_exe PRIVATE sfml-graphics)
and have everything linked as needed.

This still means that the user will have to copy more DLLs next to his executable than what he actually specified in target_link_libraries() call. But I guess this is ok.

37
General / Re: FindSFML.cmake users, help test the new SFMLConfig.cmake
« on: February 10, 2018, 11:08:57 pm »
Quote from: eXpl0it3r on February 10, 2018, 07:13:26 pm
What if the graphics module isn't installed?
Then it'll be reported as not found (if specified in components of the find_package() call)

Quote from: eXpl0it3r on February 10, 2018, 07:13:26 pm
What's the point of having to specify it when you always have to mention them all anyways?
I didn't understand what you mean here.

Quote from: Laurent on February 10, 2018, 07:18:23 pm
I can live with it if there's no way around it. But if we can make it consistent (ie. find_package(X Y) and target_link_libraries(X Y)) then I guess we should do it.
It's most likely possible to deduce that if the user asked for "graphics" component then we should also consider "window" and "system" to be among the requested components. Will fix that.

38
General / Re: FindSFML.cmake users, help test the new SFMLConfig.cmake
« on: February 10, 2018, 06:27:34 pm »
Quote from: Laurent on February 10, 2018, 06:21:35 pm
Your examples imply that find_package must contain the full list of SFML components, not just the final ones (ie. sfml-graphics sfml-window sfml-system instead of just sfml-graphics); whereas in target_link_libraries you can just give the final modules and all the dependant ones will automatically be linked. Is that the case?
Indeed. Do you find this disturbing?

39
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)

Thanks!
Ceylo

40
SFML development / Re: iOS development progress
« on: January 30, 2018, 10:04:24 pm »
Tried a bit to have SFML compiled for iPhoneSimulator but it can't find OpenAL headers. I just set IOS_PLATFORM to SIMULATOR64 as you suggested in CMake GUI.
(click to show/hide)

In file included from /Users/ceylo/Development/SFML/src/SFML/Audio/ALCheck.cpp:28:
/Users/ceylo/Development/SFML/src/SFML/Audio/ALCheck.hpp:33:14: fatal error: 'OpenAl/al.h' file not found
    #include <OpenAl/al.h>
             ^~~~~~~~~~~~~
1 error generated.

I'm using Xcode 9.1 and current master branch of SFML repo. Not all changed to get it working are pushed to master branch?

41
Audio / Re: sf::Music hangs the app with PhysFS
« on: January 28, 2018, 11:10:36 pm »
Did you try to pause your app while it's using 100% CPU to see what's the callstack of the different threads at that moment?

42
SFML development / Re: iOS development progress
« on: January 28, 2018, 11:00:31 pm »
Quote from: eXpl0it3r on January 28, 2018, 06:17:10 pm
Pretty much right after Laurent did the initial implementation of the iOS port, he said, he didn't want to maintain it. Ever since we haven't had any maintainer and generally the interest was quite low.
Oh ok. Do you know how far it went?

Quote from: eXpl0it3r on January 28, 2018, 06:17:10 pm
Jonny has been fixing up iOS in the past few weeks and I'd be happy to add him as iOS maintainer if he wishes it.
Now you've put pressure ;D (good luck Jonny)

Quote from: eXpl0it3r on January 28, 2018, 06:17:10 pm
Android and iOS are build on completely different tech, so problems are most often not shared, unless they are of a architectural matter.
Given that we don't have anyone maintaining thr iOS code, there was so far no need for synchronization.
Hmm I don't know enough about both platforms but my feeling says there is a lot to share: how to design the input API and the window API, how to deal with sandboxed resources (in terms of API), should it be a different API from SFML's desktop one, or just an extended one (probably with feature that wouldn't apply to desktop platforms). Things like that. As for the background stuff yeah it's very different, but that's just implementation detail, you're free to do what you want there, you don't need to talk to people (huhu) to decide what to do. So I find this part easier and less time consuming.

Of course if there's no maintainer there's no synchronization. I thought there was one :)

43
SFML development / Re: iOS development progress
« on: January 28, 2018, 05:34:09 pm »
This is really nice to get some kind of status about iOS development.
I've seen some IOS "if" conditions in CMake code but always wondered how to actually do an iOS build. Now I know :D

Is there a more or less defined list of what's left to do before it can be publicly released? I saw your notes but I don't expect them to be complete.

Are you the main maintainer of the iOS port? Are you currently working alone on it? Also I'm wondering, in case there were other maintainers in the past, who they were and up to where they went.

And one more question (sorry ;D ), how is the iOS port being made consistent with Android port? Both are mobile platforms and I'd expect that problems that affect one platform are very likely to affect the other one. So I'd expect kind of a synchronized development to ensure common API and shared solutions when appropriate.

44
General discussions / Re: Why is SFML still using CMake 2.8 ?
« on: January 11, 2018, 11:37:24 pm »
It's getting too big for my taste so if improvements can be merged little by little they'll also be available earlier. Also the more changes I keep in the config PR, the higher the probability of conflict with other changes merged to master.

45
General discussions / Re: Why is SFML still using CMake 2.8 ?
« on: January 11, 2018, 11:21:35 pm »
The old CMake requirement is playing tricks to me for the PR about config file.
I identified an issue that gets fixed just by updating CMake requirement, so will do a PR to update CMake requirement first.

Especially I hadn't realized that changing the required CMake version changes the default CMake policies.

Pages: 1 2 [3] 4 5 ... 69