SFML community forums
Help => Window => Topic started by: filchermcurr on August 23, 2015, 03:09:58 am
-
... or any high DPI displays in general, I guess!
I hope this isn't too silly of a newbie question! I've noticed that SFML seems to handle scaled resolutions differently than GLFW. When GLFW creates an 800x600 window, it looks appropriately sized when using a scaled resolution in OS X ('looks like 1440x900' for those curious of which scaling setting). When SFML creates an 800x600 window, though, it's tiny. It looks like SFML is basing the size of the window on the actual monitor resolution rather than the scaled resolution. Here's a screenshot of both running at the time time for comparison:
http://imgur.com/TvZ4m2F
Are there any options to make SFML behave more like GLFW on a high DPI display?
Thanks!
SFML Version: 2.3.1 from 94dd1d7
Minimal GLFW source: http://pastebin.com/F7L35Sap
Minimal SFML source: http://pastebin.com/Wurcxeig
-
Yes, you just need to add NSHighResolutionCapable to your application's plist file. But if you use the SFML template for Xcode it's done for you.
-
you just need to add NSHighResolutionCapable to your application's plist file
What if I'm distributing a plain executable file, not an .app bundle with a plist?
Right now SFML is forcing the following situation: The high-DPI users of my program have to explicitly go into the preferences and specify that they want their window to be scaled 2x to get a normal-sized window. (Since there's no way to detect high-DPI vs non-high-DPI programmatically.)
SDL2 doesn't have this problem. Instead it just works: Windows have the same virtual size on high-DPI and non-high-DPI displays, with no need to specify NSHighResolutionCapable anywhere. In addition, it's possible to detect high-DPI vs non-high-DPI programmatically.
-
I'm not trying to sound rude, just want to point out that we're neither SDL nor GFLW. Every library has their quirks and things that work and doesn't work, so there's really no use for "but library X has feature Y!!". ;)
We're always open to suggestions and even better contributions. Check out the feature request forum (http://en.sfml-dev.org/forums/index.php?board=2.0) and the contribution guidelines (http://www.sfml-dev.org/contribute.php).
-
What if I'm distributing a plain executable file, not an .app bundle with a plist?
This is not the typical thing to do on OS X, actually.
there's no way to detect high-DPI vs non-high-DPI programmatically
it's possible to detect high-DPI vs non-high-DPI programmatically.
I'm confused. ::)
Anyway, even if it is possible to do it, the advantage of application bundles on OS X over regular binary files is so huge that I don't really see the point of adding such mechanism, especially since it would actually force every application to use high res settings.
-
Yes, you just need to add NSHighResolutionCapable to your application's plist file.
I finally tried this out; made an .app bundle with NSHighResolutionCapable set to true in its Info.plist. However, the created window is still the same size as it was before this: half of the size I requested. Is this a bug?
-
This isn't so much as a bug as it is just how SFML works right now. Currently, SFML does not distinguish between physical pixels and virtual coordinates, and it is impossible to add without significant API changes (see here (http://en.sfml-dev.org/forums/index.php?topic=17092.0) for discussion).
So if you are developing for OS X, you can either set NSHighResolutionCapable to true, but deal with having your windows open small/other scaling issues, or you can set NSHighResolutionCapable to false, but have your app seem "blurry" on retina displays.
I also put together a little project here (https://github.com/joelhoover/SFML-NSHighResolutionCapable-Demo) that will build two apps from the same codebase, one with NSHighResolutionCapable true, and the other one false, making it really easy to see how this option affects an application.