SFML community forums
Help => Graphics => Topic started by: Orfby on August 15, 2015, 10:37:22 am
-
As a gamer myself (with two monitors), I hate when games do this. Basically, when I go into fullscreen mode, all my moinitors go black for a few seconds, but the second monitor never turns on until I quit the game, and then all the windows on my second monitor get moved to my primary one. If the window isn't the correct resolution, my monitor decides to auto-adjust at whatever resolution the game is at, and then don't change back after quitting the game. I'm currently on Linux (Ubuntu specifically), and I haven't tested windows, but since almost all games on Linux use OpenGL (and I'm pretty sure SFML does too) is there any way to fix this?
I'd assume I don't need a minimal example since its obvious how to go into fullscreen in SFML
-
We've had similar reports before, but without detailed information there's not really much that we can do.
What exact SFML version did you use?
Which Ubuntu version do you use?
What's your window manager?
etc
-
System Info:
- My SFML version is 2.1
- My Ubuntu version is 14.04
- My window manager is Compiz (according to wmctrl -m)
- I have a Nvidia GTX 750 Ti graphics card
- I'm using the NVIDIA binary driver, version 346.82 (proprietary)
- I'm using Unity (not the engine), version 7.2.5
I'd be happy to give any other relevant information
-
Well you're using an outdated SFML version. Try SFML 2.3.1 or the current master branch.
-
I've update to the latest version on the website, and (other than breaking my current code) it did nothing. Fullscreen still breaks my resolutions and turns off my monitor unfortunately (I also get this error when linking to the audio .so file: /usr/lib/libsfml-audio.so||undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)@GLIBCXX_3.4.20'|)
-
You should rather build from source, at least that will remove the GLIB incompatibility.
-
This is actually a common sort of situation.
The problem, though, lies with the OS. It has no idea what to do when an application changes to fullscreen. It generally changes the size of the operating system's desktop temporarily and tries to reset it back to its previous size when fullscreen is exited.
When the desktop is shrunk to match, everything on your second screen will be fit onto your first, since we'd be annoyed if it just deleted them. Then, when it resizes it back to the size you were originally working on, they're already sat neatly on the first part of the display so it doesn't fix them.
Since the OS generally acts badly here, it's also the fault of part game/part gamer. The game that cannot play in a display filling the screen rather than changing the monitor resolution, or a gamer that insists that it should be in 'fullscreen' mode rather than the previous described method, aren't helping matters.
There are other options to lower monitor resolutions but games don't care about multi-monitor users since they're less common in gaming so still to force the old fullscreen mode down our throat.
You have a possible solution, as a developer: don't go into fullscreen. Instead, use full-sized windows that cover the screen (if you really need to fill the screen). If you need a lower resolution: render textures and/or shaders.
-
The OS doesn't act "randomly" or at its own will. It exposes functions to let developers control how thing should happen. Just because the behavior is different for different fullscreen applications it doesn't mean nothing can be done about it. We'll just have to analyse it further. ;)
-
This is because of how X implementations treat multiple monitors differently compared to Windows.
X (at least implementations that I've used) by default has all monitors on one screen. When you go fullscreen, you change the screen size. If this is smaller than the screen with multiple monitors, extra monitors are disabled, because the screen no longer spans all of them.
In Windows, by default, each monitor has its own "screen". Unless you enable Nvidia surround/AMD equivalent/etc, which do what X does by default. If you enable that on Windows, you'll get the same behavior as you do on Linux.
This is why many games on Linux, for fullscreen, actually create a fullscreen window.
You could make each monitor have its own X screen, but, that's a user configuration choice, which an application cannot (and should not, imo) change.
-
Since 2.3, SFML already resorts to "soft fullscreen" (i.e. borderless window) through the window manager if it does not have to perform a mode set e.g. if the application requests fullscreen at the same resolution as the desktop. Monitors will only be disabled if the application forces the system to change the resolution of the primary screen which can encompass multiple monitors. What other libraries might do is explicitly target specific monitors and tell them to change their resolution and position their borderless window at the origin of that monitor. Currently, SFML does not provide any method of specifying which monitor to go fullscreen on and there is no way to determine which monitor the window is currently displayed on (if it is even entirely on a single monitor) so targetting monitors with mode sets is risky at best. If something goes wrong, SFML would end up changing the resolution of a monitor on which the window isn't even displayed.