Messages

16

SFML development / Re: Removing dependency binaries

« on: February 25, 2019, 05:48:16 pm »

RE SFML_USE_SYSTEM_DEPS - I agree, this is also what I suggested earlier.

I still would prefer to use git submodules over just copy/pasting the code into the repo. I will concede it adds a tiny bit of complexity for the end user, but I think it makes it easier for contributors, particularly for maintenance and testing features/bugs in different versions of dependencies. Other than having to add an extra parameter to your first clone of the repo, all the downsides of submodules are also present when just including the raw source

I don't feel particularly strongly about it though, so I'd rather just decide on a direction so we can start implementing something

For reference, freetype2 takes <8 seconds to build on my laptop, I doubt there's much deviance from that

Update: Having gone back to the work I've done previously on this, one of the larger issues is handling the target exports as we need all the dependency targets to be part of the export target, assuming we use add_subdirectory. This might require a small amount of patching for each dependency

Another update: Proof of concept using submodules here if anyone wants to check it out https://github.com/JonnyPtn/SFML/tree/build_deps .Having a slight issue on macOS where there's an openAL thread chewing up all the CPU (any ideas on that?). Otherwise, it's working pretty well

17

SFML development / Re: Removing dependency binaries

« on: January 30, 2019, 02:00:38 pm »

Relying on the user to provide the binaries assumes the correct version will be available. I'd prefer for this to be an option rather than the default (Applies to all platforms, as vcpkg can easily provide all dependencies on windows too). We also already have a "USE_SYSTEM_DEPS" flag for exactly that reason

Also updating submodules shouldn't be tedious at all - it's just a small handful of git commands and shouldn't take more than a few minutes

I think submodules + CMake's ExternalProject would be really nice to use

ExternalProject can be given a git repo and commit to checkout, so there would be no reason to use the submodules. I see these options:

- Use git submodules and just add_subdirectory() in cmake.
- Use ExternalProject which does a git checkout and build when sfml is build
- Use FetchContent and add_subdirectory

Personally I like option 3 best, but I think FetchContent is only available in cmake 3.11 so that would require a version bump.

Options 1 and 3 allow the dependencies to be configured at the same time as SFML is configured, whereas option 2 would configure the dependency at build time so you'd need to hardcode some values in the cmake configuration

18

SFML development / Re: Removing dependency binaries

« on: January 26, 2019, 08:22:03 pm »

I'll help as much as I can.

Personally I think it would be a good idea to either use git submodules or cmake to maintain the dependency source code (I'd prefer the latter). They would both allow easier dependency updates, make it easier to identify which version of the dependency is being built, and make it easier for contributors to build against different dependency versions if needed

The only down side would be if the user clones the repo (and forgets to clone with submodules) then goes offline they will not be able to build SFML, but I think this is a rather specific and rare case

19

General / Re: OSX Sierra static runtime broken

« on: August 27, 2018, 12:50:51 pm »

Milerius, Give this Pull request a try if you can. It should solve the issue: https://github.com/SFML/SFML/pull/1485

20

Window / Re: glCheck() not available in window module

« on: August 16, 2018, 08:10:38 am »

So is there any reason that it couldn't/shouldn't be in the Windows module? What's the "rule" that EAGLContext is an exception to? Just that openGL isn't "normally needed"? Is the argument just that it makes more sense to be in the graphics module? Would you accept if it was duplicated in the windows module? or just defined in EAGLContext.mm?

Regardless of that specific issue (I only mentioned it for context), would it not be an advantage to have gl error checking wherever possible?

21

General / Re: Travis build file?

« on: August 16, 2018, 07:52:33 am »

I do it slightly differently and just use the default install paths. This set up builds with multiple compilers and for macOS (it's a little messy I admit...) https://github.com/JonnyPtn/SFML-DOOM/blob/master/.travis.yml

22

Window / glCheck() not available in window module

« on: August 15, 2018, 04:49:50 pm »

While trying to debug https://github.com/SFML/SFML/issues/1471 I noticed that none of the gl functions in the windows module are wrapped by glCheck(). As it's defined in the graphics module this makes sense, because the window module doesn't (and shouldn't) depend on the graphics module. But I was wondering if there was a reason this couldn't be moved into the window module, so that we can error check all the gl functions there as well?

23

Feature requests / Re: sf::Rect extension

« on: August 14, 2018, 05:31:51 pm »

Bumping as this is now in 2.6.0 discussion - Any disagreement on adding the setters?

24

General / Re: SFML 2.5 CMake Migration

« on: July 31, 2018, 08:28:37 pm »

arnavb - regarding backward compatibility, FindSFML.cmake should still work, and (if found) will be used before the new config setup, so this isn't strictly a breaking change

25

General / Re: OSX Sierra static runtime broken

« on: June 23, 2018, 01:07:21 am »

https://developer.apple.com/library/archive/qa/qa1118/_index.html

along with other resources is where I was getting the info from. And indeed, if I try and create a statically linked binary, I get the expected error.

Using SFML static libraries however doesn't error, and has the expected behaviour (in that the binary works without including the SFML libs)

26

General / Re: OSX Sierra static runtime broken

« on: June 21, 2018, 07:34:16 am »

there's a bit of ambiguity here if I understand correctly:

static libraries are supported by Apple (and presumably by SFML too?)

statically linked binaries are not supported by Apple (and therefore not by SFML either?)

I think OP is trying the former? I wouldn't claim to be an expert, so please correct me if I'm wrong

27

General / Re: OSX Sierra static runtime broken

« on: June 21, 2018, 04:52:50 am »

Might not be officially supported, but does work - Milerius can you try adding -all_load to your other linker flags?

28

SFML development / Re: iOS development progress

« on: April 25, 2018, 06:42:21 pm »

There's a few outstanding PR's which could do with testing:

• https://github.com/SFML/SFML/pull/1418
• https://github.com/SFML/SFML/pull/1417
• https://github.com/SFML/SFML/pull/1412

29

General / Re: [iOS] SFMLConfigDependencies.cmake looks for OpenGL

« on: April 13, 2018, 02:35:35 am »

There's a PR which should address this now: https://github.com/SFML/SFML/pull/1416

30

Window / Re: iOS incorrect window size on reorientation

« on: April 12, 2018, 03:23:15 am »

I've finally got round to debugging this a bit more, and have found there's a couple of things which came together to cause this:

• I haven't been specifying a window style, presuming it was being ignored on iOS, but the autorotate flag is being set based on whether sf::Style::Resize is set. This means specifying sf::Style::Fullscreen (or any style without the Resize bit set) stops the screen from rotating (https://github.com/SFML/SFML/blob/5d7843c58a850b4941d7d9794d6fede2bbc02833/src/SFML/Window/iOS/WindowImplUIKit.mm#L86)
• When the autorotate flag is set, the screen rotates based on the supported orientations defined in the Application bundle properties (Info.plist). If this property doesn't exist, then the OS seems to assume that all orientations are supported, however SFML assumes none are supported (https://github.com/SFML/SFML/blob/master/src/SFML/Window/iOS/SFAppDelegate.mm#L176)

For the first point, I can kind of see the connection now between autorotation and sf::Style::Resize, however I don't find it terribly intuitive. I'd prefer a more explicit way of specifying whether to autorotate or not, does anybody have an opinion on how this could fit into the API?

For the second point, I'd say we should assume the same as the OS, which simply means changing it to return false on the line I linked above. This means the event contains the correct window sizes, however upside-down orientation doesn't look completely correct...

I think for the second point it actually needs to return

(1 << orientation) & [rootViewController supportedInterfaceOrientations]

but have SFML's override of supportedInterfaceOrientations removed, because the override just returns that all orientations are supported, whereas the default returns different values for iPhone/iPad, and matches what I'd expect (and fixes the issue) based on documentation here: https://developer.apple.com/documentation/uikit/uiviewcontroller/1621435-supportedinterfaceorientations

I'm still kind of learning this as I go along, so anybody with more experienced input please speak up!