Messages

1

Graphics / Re: Inconsistency in sf::Image::copy

« on: July 21, 2016, 03:32:36 pm »

Seems like left/top would just need a similar test to make your second example work.

In addition to that the destX and destY parameters would need to be int, rather than unsigned int.

2

Graphics / Re: Inconsistency in sf::Image::copy

« on: July 21, 2016, 02:38:49 pm »

What is the red rectangle, what is the green rectangle?

Please read the post.

3

Graphics / Inconsistency in sf::Image::copy

« on: July 21, 2016, 02:25:20 pm »

sf::Image::copy allows the images to overlap like this (red is the target image, green is the source image):



but not like this:



I think this behavior is inconsistent. Is there a rationale for this or is this just an oversight?

4

Window / Re: Window Size On Retina Macbook Pro

« on: July 20, 2016, 06:38:15 pm »

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?

5

Window / Re: Window Size On Retina Macbook Pro

« on: April 10, 2016, 08:09:34 pm »

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.