1
Window / Re: 0 fullscreen modes available on 14inch macbook pro
« on: November 18, 2022, 12:46:26 pm »
Which versions of macOS are you on?
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.
2
Feature requests / Re: Add .setSmooth() for text
« on: August 12, 2020, 08:44:37 pm »
Have created a pull request for this: https://github.com/SFML/SFML/pull/1690
3
Window / Re: Legacy MacOS NSOpenGLPixelFormat failure and fix
« on: February 03, 2020, 11:58:03 pm »
Related issue: https://github.com/SFML/SFML/issues/161
Looking at the documentation it seems like NSOpenGLPFANoRecovery disables the fallback (software?) renderer, and I quote: "This attribute is not generally useful."
And the docs for NSOpenGLPFAAccelerated: "If present, this attribute indicates that only hardware-accelerated renderers are considered. If not present, accelerated renderers are still preferred."
Based on this, I'm wondering if we can just remove the line altogether rather than just putting it in a version check? If you want to open an issue (or a PR with that change if you like) then feel free, otherwise I'll put something together this weekend
Looking at the documentation it seems like NSOpenGLPFANoRecovery disables the fallback (software?) renderer, and I quote: "This attribute is not generally useful."
And the docs for NSOpenGLPFAAccelerated: "If present, this attribute indicates that only hardware-accelerated renderers are considered. If not present, accelerated renderers are still preferred."
Based on this, I'm wondering if we can just remove the line altogether rather than just putting it in a version check? If you want to open an issue (or a PR with that change if you like) then feel free, otherwise I'll put something together this weekend
4
Feature requests / Re: Friendly string mapping to Keyboard::Key
« on: January 30, 2020, 01:13:39 pm »
This is actually something that will be provided by `getDescription` as part of the scancode API
You can take part in the discussion and test it here: https://github.com/SFML/SFML/pull/1235
You can take part in the discussion and test it here: https://github.com/SFML/SFML/pull/1235
5
General discussions / Re: cmake errors in WSL Ubuntu
« on: January 20, 2020, 04:48:46 pm »
Don't think this is a problem with WSL, more likely a problem with MXE (which is completely alien to me, so can't offer much help there)
Little confused why you're calling a mingw script in WSL (which is for all intents and purposes a linux system) too?
Little confused why you're calling a mingw script in WSL (which is for all intents and purposes a linux system) too?
6
Feature requests / Re: XInput support
« on: October 14, 2019, 02:55:12 pm »
It would mean on windows we'd need to link xinput, which I don't see being a problem except perhaps if using minGW, in which case we can just add a macro to disable it.
In terms of the API, I don't think there should be any changes. The implementation would be mostly the same (update the state every frame). Down the line we may want to consider a way for the user to check if a device is using xinput or not, but that would probably be part of a wider gamepad recognition feature
In terms of the API, I don't think there should be any changes. The implementation would be mostly the same (update the state every frame). Down the line we may want to consider a way for the user to check if a device is using xinput or not, but that would probably be part of a wider gamepad recognition feature
7
SFML development / Re: Removing dependency binaries
« on: August 30, 2019, 10:27:03 pm »
Don't suppose there's been any decision either way on this?
8
General discussions / Re: External libraries' versions
« on: April 26, 2019, 12:11:38 am »
The versions of the pre-built libraries varies by platform (All the more reason to get them build as part of the source tree: https://en.sfml-dev.org/forums/index.php?topic=25053.0)
This repository contains the revisions of each of the dependencies which is known to work with SFML on all platforms: https://github.com/eXpl0it3r/SFML-dependencies
This repository contains the revisions of each of the dependencies which is known to work with SFML on all platforms: https://github.com/eXpl0it3r/SFML-dependencies
9
General discussions / Re: Android x64 support
« on: April 26, 2019, 12:09:17 am »
Should be easily solvable once there's a decision on how to build deps from source: https://en.sfml-dev.org/forums/index.php?topic=25053.0
10
General / Re: CMake android build errors
« on: March 22, 2019, 07:18:59 pm »
I beleive you're looking for x86_64 (_ instead of -)
11
SFML development / Re: Removing dependency binaries
« on: March 14, 2019, 06:35:13 pm »
Personally I don't think it's a good idea to add another requirement/dependency like that just to manage our dependencies
12
SFML development / Re: Removing dependency binaries
« on: March 11, 2019, 03:14:27 pm »
Subtree looks like a reasonable compromise, although information on it is a little thin spread.
It doesn't have to be - the submodules can be cloned/updated as part of the cmake script
Ultimately I don't mind too much, I'm just keen to see a decision made, if you have a better suggestion than a poll to get this done that's absolutely fine by me.
Quote
We also have to consider that using git-submodule is a breaking change for everyone that has a more or less automated workflow (bash/batch scripts that update and build SFML).
It doesn't have to be - the submodules can be cloned/updated as part of the cmake script
Ultimately I don't mind too much, I'm just keen to see a decision made, if you have a better suggestion than a poll to get this done that's absolutely fine by me.
13
Window / Full screen problems on macOS Mojave
« on: March 10, 2019, 04:15:09 pm »
I'm getting a very strange issue with full screen: When turn full screen on then off again, the window is duplicated so I have two instances of the same window (but one doesn't have any render context, just a blank window).
I'm on macOS mojave building with Xcode 10. I'm aware there are some other issues in the latest SDK with openGL so I'm wondering if anyone else can confirm this issue?
I'm on macOS mojave building with Xcode 10. I'm aware there are some other issues in the latest SDK with openGL so I'm wondering if anyone else can confirm this issue?
14
Window / Re: iOS Sample Code
« on: March 10, 2019, 04:12:36 pm »
The latest version of the pong SFML example implements touch input
15
SFML development / Re: Removing dependency binaries
« on: March 08, 2019, 11:46:12 pm »Quote
Git submodules were a pain every single time I had to do more with them than just git clone --recurse-submodules.
You wouldn't have to do anything more with them than just git clone --recurse-submodules
Quote
Less user-friendly for every SFML user due to extra setup step (you can expect 100s of forum posts "why does my code not compile")
It can be made extremely simple. We can use cmake show a warning if the user hasn't cloned the submodules, telling them exactly which command to run. We can also use cmake to actually check out the submodules if the user hasn't already
Quote
We introduce a third-party dependency. If that third-party repository goes down, SFML will not be possible to build, with no backup (rolling back to previous version past now won't work)
Given all the repositories except one are hosted on github, the likelihood of this being an issue is almost nil. If it's a concern we can also easily mirror them in repos we have control over
Quote
It's not even clear if all the dependencies we currently use have official and stable Git repos. If not, we would need to provide a mirror (i.e. extra maintenance).
They all have official git repositories, and even IF we were to mirror them (which I don't think we need to do) the maintenance would be equal to maintaining the source in the SFML repo (i.e. almost nil)
subtree looks interesting. Haven't tried it myself but worth considering. I'd be interested to see and try a working example of it
Quote
And I would appreciate if the decision were made based on technical arguments, not polls from a handful of people that happen to be around at the time the matter is discussed
I think we've pretty much already covered all the technical arguments, there's not really too many facets to discuss. At this point it comes down to personal preference, so a poll seems reasonable.
In the interest of fairness, here are the submodule advantages that were already mentioned:
- Better visibility over dependency versions
- Easier testing of newer dependency versions (just git checkout/pull the revision you want to test)
- Easier access to dependency history for bisecting/debugging/testing
- Less risk of human error when updating or changing dependencies
- Easier to contribute changes upstream
As I said before I don't think there's a clear technical reason to choose one or the the other (They are almost identical in practice) so we just need a decision made. It's super easy to change and the implementation is pretty much done. We just need a decision so this doesn't turn into another dead discussion