SourceForge has been redesigned. Learn more.

#145 Game does not start up full screen


When you launch FreeOrion, it starts up in a teeny tiny window. I immediately clicked Options to look for a "make it go full screen" button, or better yet, an "always start in full screen" checkbox. Instead what I found was a pair of pop up menus which offer resolutions for full screen and windowed modes, followed by the unhelpful text "restart in full screen to take effect".

Now, you may not have noticed this, but the user is not presented with any way to choose whether to run in windowed or in full screen when they double click on the application icon! Quitting and relaunching the app after changing the fullscreen resolution pop up value does not help. It still launches windowed.

Firstly, the game should run in full screen by default.
Secondly, there should be a checkbox in the Video Options to switch to windowed mode for future launches.
Thirdly, there should be a menu item, button and command key available to toggle between windowed and fullscreen mode. I humbly suggest ⌘F.


  • Geoff Topping

    Geoff Topping - 2010-07-24

    To start in fullscreen, run "freeorion -f"

    I don't know how things work on MacOSX, but presumably you can access a console window or edit the application icon. On Win32, there are separate shortcut links for windowed and fullscreen modes. I don't know if doing something similar (ie. multiple launcher icons for multiple modes) would be suitable for the OSX GUI, but if so, it could be.

    The game is quite deliberately NOT started in fullscreen by default, because doing so would mean that if there is a crash or hang, the entire system could become unusable. In windowed mode, if the game hangs, then the window can be easily closed as the rest of the OS GUI remains accessible.

    This is also why there isn't a toggle in the GUI to start in fullscreen mode on future launches. If something in the configuration was messed up such that the game hung immediately after starting, but it was stuck launching in fullscreen mode, the user would be unable to recover without editing a config file as they would be unable to get into the options GUI to uncheck the fullscreen toggle.

    Switching between windowed and fullscreen while the program is running is not possible at this time. Hence the instruction to restart in fullscreen.

  • Nicholas Shanks

    Nicholas Shanks - 2010-07-24

    Somebody who is a competent command line user, such as myself, could do that (now that I know how: pass a flag—I had tried double clicking while holding down all sorts of key combos to see if that would do it, but alas not), however there is no way on Mac OS X to do pass flags to .app bundles easily as you can to a Windows .exe by creating a shortcut and editing the shortcut properties. People who are only comfortable double-clicking things won't be able to run it fullscreen at present.

    The developers could ship with two binaries as you suggest (with the additional flag specified one of the two property lists), but it would require twice as much disk/download space, as all media would need to be duplicated as well, just for a minor change in the Info.plist file.

    A good way would be as I had tried: look for a modifier key held down during app launch. (Shift, Control, Option or Command—Option/alt would be best as the other three can interfere with a double-click). This could simply do an "override current options setting" so that people who normally start in fullscreen can easily start windowed if they need to.

    As for not starting in fullscreen for safety reasons, as long as you do not gobble all key presses, and you do not override Command–H (hide application) nor Command-Tab (switch application), then you can't lock the user out of the system on OS X. When your application is sent to the background, then if you have captured the display (CGCaptureDisplay) it gets released by the OS on your behalf, or if you instead just display a fullscreen window, hide the menu bar and dock, and blank the other screens yourself, then you can set a boolean on creating the window which says "only display this window when the app is in the foreground" (tool palettes often use this) and the window manager will not blit your window's backing buffer to the screen. Similarly, the mouse will be re-associated if your app disassociated it using the CGAssociateMouseAndMouseCursorPosition(false) system call.

    "Switching between windowed and fullscreen while the program is running is
    not possible at this time."
    I would have no objections to that holding true during a game, but before loading a game, when you're at the menu, it does seems a bit harsh. I hope it is on the TO DO list :-)

  • Geoff Topping

    Geoff Topping - 2010-07-24

    Whether a game is being played or you're looking at the menu, the situation is the same: the OGRE GUI has been started up in either fullscreen or windowed, and switching isn't easy without restarting the whole GUI.

    What keypresses are "gobbled" depends on the OGRE input plugin that we're using. The OIS plugin isn't particulary good, and certain types of errors have caused hangs and apparent inability to get back to the OS GUI in the past, at least on other OSes.

    As far as I know, FreeOrion also doesn't do any direct calls to create windows or hide docks or whatever else; it's managed by the OGRE library.

    There may be ways to handle these issues better in general or on OSX in particular, but figuring out how to do these things within the OGRE framework unfortunately isn't a priority now.

    Patches are welcome, of course.

  • Nobody/Anonymous

    It's been a while since I looked at OGRE stuff, but I remember the tutorials would start up with an independent dialog that allows you to choose resolution settings before the actual application runs.

    Ogre::Root::showConfigDialog() looks like the way to access it.
    Ogre::ConfigDialog looks looks like it could be subclassed if the dialog needs to be customized (which I'm sure would eventually be desirable).

    This would give us a platform independent way (via the OGRE framework) for the user to select resolution and fullscreen settings on application startup.

    The dialog could also have a "remember settings" option (not sure if it comes with one by default).

    Then, if the config dialog pops up on first-time application use or when an "unclean exit" is detected, I think this addresses the concern about the user being stuck with bad settings.

    The "unclean exit detection" would probably be something like writing a flag to a file during a canonical exit routine and then clearing that flag on application startup. If the flag doesn't exist, show the config dialog. The flag would not exist for first-time startup.

  • Jonathan Siwek

    Jonathan Siwek - 2010-07-25

    Sorry that last comment was me.

    I do think my suggestion might be a good long term fix.

    In short term, I guess a shell script could be distributed for OS X clients that just does something like: -f

    In order to give OS X users an easy way to run fullscreen. But that's a little shady and I think it would be bad for users to get used to that way. It might be sufficient enough to document it for now?

  • Geoff Topping

    Geoff Topping - 2010-10-11
    • milestone: 1120756 -->
  • Geoff Topping

    Geoff Topping - 2010-11-22

    I've added a fullscreen toggle and an apply button on the options screen. At least on Windows, this lets the user change video modes without restarting. This won't do anything for storing fullscreen for the next exectuion, however.

  • Geoff Topping

    Geoff Topping - 2011-08-07
    • status: open --> closed