[Mac] Fullscreen modes not scaled to screen size

[BlueCobold]

Any news on this topic?

[Hiura]

No, not really. :-/

Since the discussion is quite long and comments are scattered in various places, let's try to recap with a proposition. Please tell me if it makes everybody happy. 

I'd say we should introduce a second fullscreen style flag:

• one for hard switch, and
• one for soft switch which would fill most of the screen without stretching (i.e. it would respect the ratio asked by the user).

What do others think?

[Laurent]

I haven't read the full topic, but that:

one for soft switch which would fill most of the screen without stretching (i.e. it would respect the ratio asked by the user).

... sounds like an ugly hack

It also sounds like a user problem (scaling, stretching, resizing, whatever... properly the window and/or view inside it) rather than a feature to add to SFML.

[mkalex777]

I have a small question about it.
What is the better:
1) adjust all View parameters on resize event only
2) adjust all View parameters on every frame

I'm using 2, so the view always contains correct parameters.
But may be it's bad from performance perspective...

View parameters: center position, size, viewport

[BlueCobold]

Wrong topic, dude. But in the end, it doesn't matter, you won't notice any performance issues. It would be enough to make it on resize, but it's no problem to do it every frame.

[Hiura]

... sounds like an ugly hack

Tell that to SDL's team =P https://wiki.libsdl.org/SDL_SetWindowFullscreen

More seriously:

After reading this discussion again plus the one on github, I understand and agree that a hard-switch is needed, but the question remains if we want to provide a soft-switch.

Beside going along Apple's policy, it can be seen as a convenience feature for the users. Regarding SFML's philosophy, it's indeed against the "slim API" aspect, but I believe it fits well in the "pragmatic" one.

[Laurent]

I guess we need a concrete example: how would the soft-switch be implemented, if done entirely on user side?

[BlueCobold]

Basically by rendering into a RenderBuffer and then rendering this in a scaled version (keeping aspect-ration by adding black areas or not keeping it by filling the full screen) to the desktop resolution. I still understand the Apple hint like: "Don't change without asking" which actually is a good advise for any kind of game imo - switch only if the user wants to explicitely (via menü or config files). However, I'm not sure that Apple compliance is a topic for SFML at all. And even if SFML would implement soft & hard-switch, the games using SFML would still need different code for different systems, because of not allowing to hard-switch resolutions on OS X (and thus using soft-switch on OS X and using hard-switch everywhere else). So either make it a hidden soft-switch on OS X being true fullscreen or change it to a hard-switch. Both of these would result in what the devs expect. I don't think the devs need both options as long as the result looks correct.

[Hiura]

There's not only the display to be taken care of. The inputs (e.g. mouse coordinates) need to be adjusted as well.

Performance wise, it might be better to take advantage of some unexposed backbuffer -- but I didn't test this theory so it's probably not a valid argument.

[6Dragon6]

 Hello there, I am so sorry to do this necropost but would this work? It does work in Windows.

sf::RenderWindow window(sf::VideoMode(640, 320), "Proyecto001",sf::Style::Fullscreen);
view.reset(sf::FloatRect(1, 1, 640, 320));
window.setView(view);
 

 This creates a "camera" that stares only at whatever you chose, in this case the first 640x320 pixels, and stretches them to the full screen.

 This would solve the problem, however, this will not respect the aspect ratio, obviously.

 Greetings!

[BlueCobold]

No, it doesn't work. Because on OS X, the window does not fill the entire screen. The view is unimportant here. The code fills the remaining area with black. See the screenshots I had attached in my first post.

[6Dragon6]

 That's exactly what it does in Win7 if I am understanding correctly:

 Before, the remaining space of the screen is filled with black instead of stretching the game screen, the sprite and the red background keep their size (the red background represents the size of the game screen, the rest is black):
https://s32.postimg.org/a4fpvem45/project001_2016_06_26_23_19_08_91.png

 After applying a view, the game screen fills the whole thing, the sprite and the background are stretched:
https://s32.postimg.org/h4nf24bjp/project001_2016_06_26_23_19_16_49.png


 Unless I am misunderstanding something it looks like we are on the same boat, except that code worked for me.

PS: I can't seem to find the attachments you left here :/

[BlueCobold]

Windows and OS X behave different. No matter if I apply a proper view (which I'm doing) or not. Please stop discussing until you have it running with OS X. You're not helping at the moment. It works fine on Windows, Linux, Android and iOS. It does not on OS X.

[6Dragon6]

  At least I was trying to help, you are welcome, nice manners by the way.

[BlueCobold]

Don't get me wrong, but the topic and reason for the behaviour on OS X had been discussed long enough. I know you're only trying to help, but posting things about how they work on a different system, are practically not helpful. I am glad you did revive this necro-thread though, it probably still has not been changed. Has it?
The worst thing that could happen is that the thread gets closed with: "Works for me. 6Dragon6 has proven so" - although the problem still remains. Just because someone didn't read the topic in it's entirety. I want to prevent an upcoming of the idea that there is no problem on OS X at all and I'm just not clever enough to set a proper view. But it's not related to views at all.