Full screen not really full screen on Linux? |
Leszek Godlewski
Guest
|
Hi everyone,
I'm trying to get my game to work properly in full screen with input grabbed and relative mouse mode, and it's being problematic with non-native resolutions (i.e. my screen can display up to 1920x1200 and that's its native resolution; anything smaller is non-native). I'm simply calling SDL_CreateWindow() with flags of SDL_WINDOW_OPENGL | SDL_WINDOW_FULLSCREEN. This is happening on up-to-date Debian testing amd64 with KDE 4. First of all, the display mode change occurs before the window is even created, which results in displaying a cropped and rescaled fragment of the desktop (or all the other active windows) through a kind of a "crop rectangle" for a few seconds while the game starts. So this is not really a full-screen, it's just the crop window matching the dimensions of an undecorated game window. Then, the input grab does not take effect until the game has actually been rendering for a few seconds already. This makes it possible to move the mouse around while the game is loading, and since the "crop rectangle" follows the cursor, it's possible to navigate it somewhere where the game window isn't even visible. I've noticed that Valve games on Linux actually create a window that matches desktop dimensions, render to an offscreen buffer and then manually upscale it when blitting before swapping buffers. Is that the only way to achieve "real" full-screen? Are these known issues? Any suggestions on how to alleviate them? Regards, Leszek _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||
|
Full screen not really full screen on Linux? |
Sik
|
First of all: beware that proper fullscreen on Linux is broken except
when the resolution is unchanged :/ 2013/7/7, Leszek Godlewski:
Actually, I recall Windows doing the same thing (fullscreen OpenGL is just an undecorated window that covers the entire screen). It's just that you saw the window take a while to pop up after the video mode was changed... That sounds like an issue, but it's still real fullscreen.
Yeah, this is what I mean with "fullscreen is broken".
There's a "fake fullscreen" mode that does this. The video mode is not changed (which means you're stuck to the current resolution no matter what), but the window is forced to take up the entire screen. It has some of the other behaviors from windowed mode too. And yes, I also want proper fullscreen to be fixed (at least for resolutions lower than the current one which are listed as valid), but it seems it's low priority... _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||
|
Full screen not really full screen on Linux? |
Leszek Godlewski
Guest
|
Hmm. Okay then, I'll tell the QA department it's not my fault. I'll
try to look into that part of SDL code if I have the time. At the moment I'll just make the desktop resolution the default setting and call it a day. Thanks for the quick reply! 2013/7/7 Sik the hedgehog:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||
|
Full screen not really full screen on Linux? |
Sik
|
If you ever figure out what SDL is going wrong, can you tell us? :S
It's like the video mode switch works, but the desktop stays at the same size (resulting in that "crop window" you were talking about). May want to only take care of when the resolution goes lower if you decide to look into it. It's unlikely the user may want to use anything higher than the desktop's resolution, and some drivers seem to have issue reporting resolutions higher than the current one anyway. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||
|
Full screen not really full screen on Linux? |
Sam Lantinga
|
I would recommend using SDL_WINDOW_FULLSCREEN_DESKTOP for all platforms. Each platform has its own quirks with mode switching, and that's the safest way to do fullscreen on all of them.
On Sun, Jul 7, 2013 at 4:06 AM, Leszek Godlewski wrote:
|
|||||||||||||
|
Full screen not really full screen on Linux? |
Sik
|
Why not just remove SDL_FULLSCREEN then >_>'
I think the problem is more apparent with games, given they're usually very expensive on the hardware. One of the most common things to do to help improve performance is reduce the rendering resolution, however not all players like being restricted to a window. In this case proper fullscreen is going to be needed (other than really ugly workarounds like the one mentioned before). Yes, I keep hearing arguments against fullscreen. "It causes windows to be rearranged" we had this issue back in the Windows 9x days and in the end it was considered just a minor inconvenience. "Games that crash don't restore the original resolution" (outside Windows) we used to have this before too. Annoying, yes, but a crash usually means something else went wrong too, and the user can just switch back to the original resolution. "Games force fullscreen on the user" that's the fault of the game, not the feature. "Fullscreen breaks multimonitor setups" that's because the whole concept behind multimonitor is broken (they should be separate workspaces, not behave like a single giant monitor), and even then most people still have single monitor setups where this shouldn't be an issue. Back on track: does anybody know how to get X to resize the desktop to the new video mode? Even if it results in rearranged windows, I think we can agree that's a much better side-effect than having a cursor that can move off-screen. Also can we get SDL to fail to create a fullscreen window if it can't be handled properly, please? At least we wouldn't have confused programmers because fullscreen isn't working as expected. 2013/7/8, Sam Lantinga:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
Full screen not really full screen on Linux? |
Sam Lantinga
|
I have banged my head against the X11 fullscreen issues many times with no success. Ryan has a window manager proposal in that moves this into the window manager, which is really where mode switches belong, but it's gaining traction slowly.
If someone wants to dig in and tackle this issue, I'd appreciate it. Cheers! On Sun, Jul 7, 2013 at 8:23 PM, Sik the hedgehog wrote:
|
|||||||||||||||||
|
Full screen not really full screen on Linux? |
Sik
|
I don't know how to program X :/ Tried looking around but didn't find
much, other than the fact SDL seems to not set the viewport explicitly (but this only sets the top left corner, rather than the clipping rectangle) and that it should be flushing X after setting the video mode (which probably explains the lag mentioned in the initial message). I doubt that's going to help much though. Again what was the reason for making XRandR not the default? The only issues I had was that it'd reset the gamma, but honestly, that's mostly an issue specific to my system and Nvidia's drivers being dumb than anything else, changing the video mode from the system settings does exactly the same thing -_-' One quick hack I thought was to prevent the mouse from being able to go outside the window... at least that'd prevent it from scrolling off-screen. Does SDL already attempt to do something like this already? (I can see why grabbing the keyboard is an issue but grabbing the mouse when the program is fullscreen and no other window has focus shouldn't be that much of an issue - at least unless multimonitor is involved, but that already has a lot of other issues with fullscreen) 2013/7/8, Sam Lantinga:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||||||
|
Full screen not really full screen on Linux? |
Full screen not really full screen on Linux? |
Ryan C. Gordon
Guest
|
Not that I disagree with you, but the theory with SDL_WINDOW_FULLSCREEN_DESKTOP is that you render to a framebuffer object that's at whatever lower resolution you want, then use GL_EXT_framebuffer_blit (or draw a single textured quad) to the higher resolution. Some argue that the GL scales up the smaller framebuffer better than your LCD would in any case, and you can spend less on pixel shaders and fillrate by rendering at the lower resolution. Extra credit for doing it like Valve: draw the game at the lower resolution in an FBO, blast it to the screen, then draw the UI at native resolution on top of it, so text doesn't get blurry, etc.
This is an X11-specific issue, and we have a proposal pending to fix this, by adding a protocol to make the window manager handle resolution changes, so a crashed fullscreen game goes away and the window manager cleans up properly.
That's the stickier point, I suppose. As far as I know, it _does_ work on some X11 configurations (without FULLSCREEN_DESKTOP). If it's not working, and it's an SDL bug, we should strive to fix it. Part of me thinks we're going to have to abandon X11 for Wayland and/or Mir before we can completely fix this on Linux machines, though. --ryan. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||
|
Full screen not really full screen on Linux? |
Sik
|
Going to test this again later today, if I forget to do it make sure
to nag me, OK? 2013/7/8, Ryan C. Gordon:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||
|
Full screen not really full screen on Linux? |
Sik
|
Er should have removed the quote there. Oh well.
_______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||
|
Full screen not really full screen on Linux? |
Sik
|
OK, tested this with a lower resolution and so far the error seems to
be the same as before: the video mode changes, but the desktop size does *not*. Also it seems to take quite a while before it finally settles. Basically I have all the issues mentioned in the initial message. At least Alt+Tab works fine, even video mode switching. Trying to figure out a workaround. Was thinking on restricting where the cursor can go to prevent panning, but apparently that isn't doable with SDL's current API (and I can imagine why). Another option is to use relative mouse events so it's possible to mess with the cursor (and force it in a specific position constantly - no harm, given you shouldn't be able to get to other windows anyway!). Does anybody think this may work? _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||
|
Full screen not really full screen on Linux? |
gabomdq
|
2013/7/10 Sik the hedgehog
Ubuntu? KDE / Unity? nVidia / AMD / Intel? Is it using XRandr? -- Gabriel. |
|||||||||||||
|
Full screen not really full screen on Linux? |
Sik
|
2013/7/10, Gabriel Jacobo:
Ubuntu 12.04
Gnome Classic
Nvidia (proprietary drivers) Hardware: Nvidia 7300 GS (yeah...)
Whatever one is the default (so I guess it's XRandR?) Also gave a try to relative mouse events, and um, while they work... well, let's say that first I need to find out a way to handle them while the cursor is outside the window. I guess that merely getting them to work as I want is going to take more effort than even trying the hack workaround for fullscreen >_< _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||
|
Full screen not really full screen on Linux? |
Sik
|
Oh wow my idea worked O_O
Here's what I'm doing: 1) If the program goes fullscreen, enable relative mouse mode. After this we'll use SDL_GetRelativeMouseMode to tell whether it's enabled or not. 2) If relative mouse mode is on, every so often (in my case I went for once per frame) cause the cursor to wrap to the bottom-right of the screen, then the top-left, then the center (all three in a row) using SDL_WrapMouseInWindow. This forces the visible desktop area to stay on the window. 3) Use events to keep track of the mouse position (not SDL_GetMouseState). When relative mode is disabled, just store the coordinates as-is. When relative mode is enabled, just add them to the previous position (add clamping here to prevent the mouse from going off-screen). Use the coordinates you store here as the actual cursor coordinates. OK, a proper fix in SDL would be better, but for those who want to support proper fullscreen on Linux, consider trying that. There's still the ugly delay when going fullscreen, but eh, I think we can live with it (we already had to in the early days of fullscreen on Windows after all and nobody complained). _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||
|
Full screen not really full screen on Linux? |
Sik
|
After some more testing:
2013/7/10, Sik the hedgehog:
Just warp the mouse to the top-left corner. Don't bother with the other two warps. This seems to be the safest in fact. Note that all this I described is for handling the case where the resolution is lower than the desktop one (SDL fails in a different way when going for a higher one, but users would rarely want to try it anyway). Also this probably doesn't cope well with multimonitor setups, but you know what's the deal, fullscreen never worked nicely with multimonitor for starters so you probably will want to suggest going windowed or do the fake fullscreen thing (at least now you can use SDL to detect when there are multiple monitors). _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|