(CLI) Allow using --fullscreen=false to force windowed mode

[m-7761]

Is there a command-line switch to force windowed mode? (I cannot find a reference. --help etc. doesn't help.)

I would like to press F to enter fullscreen. And do so every time I start RetroArch. Is this too much to ask?

[hizzlekizzle]

You can set your main config to fullscreen = false and then set core overrides to fullscreen = true, then I think it will fullscreen itself when you load content.

[m-7761]

Just to confirm, I'm not sure what is happening, but does pressing F change this Option setting? Why would it work like that? I don't know any software where F11 for example is a directive to open in Fullscreen from hence forth. Maybe that's not what's happening, but it seems like misuse of Options if so.

EDITED: What is the value in having how it opens being essentially random? Generally when I open an application I don't want it to cover up everything. But I can see the value in that.... which is what the Option is for.

[m-7761]

@hizzlekizzle I don't want the game to go to fullscreen always. I just sometimes make it so, depending on what I'm doing. Seems like a bonehead design to me.

[RobLoach]

No need to insult the software, it's not constructive. Just need to get clear what your intended workflow is, and then put together a clear plan in order to achieve it. This is what I'm hearing you want to do...

1. Launch RetroArch in Windowed mode
2. Launch to fullscreen by pressing F
3. Quit RetroArch with the Escape key
4. Launch RetroArch, but have it in Windowed mode

When quitting RetroArch from fullscreen, RetroArch sees that the fullscreen option is TRUE, and then saves that in the configs. This is not bonehead design, it's how most users would expect the program to run... We could augment it to function in the way you intend however...

Option 1: --appendconfig="retroarch.extra.cfg"

This is a workaround you can do right now to achieve what you're looking for. Create a retroarch.extra.cfg with video_fullscreen=false. When running RetroArch, use retroarch --appendconfig="retroarch.extra.cfg".

RetroArch will append the config, overwriting what's in retroarch.cfg, effectively making it always launch in windowed mode.

Option 2: --fullscreen=false

This doesn't exist in RetroArch currently, but it would be pretty easy to add. Allowing using --fullscreen=false to force Windowed mode. I always love CLI improvements, as it means more control when launching the application.

Overall, insulting the design is not constructive. You can do better. RA is always growing, and we need your help to make it awesome. Would love your thoughts on where it could go and how it could improve. Thanks!

[m-7761]

@RobLoach No insult. Just classifying this design pattern. It's nonstandard. A fullscreen function is common, when I put a movie into fullscreen, I don't expect the next movie to launch into fullscreen. Pressing F11 (or f) is a temporary measure. And it's a pure hassle, whereas users who want their fullscreen state to be remembered (no one does, you are just thinking that if they go into full screen once that they want that setting forever, and you are saving them from finding the setting in the Options) can locate the relevant Option. I bet there are very few other options that work like this.

FWIW my thinking in reporting this was just that no one had given it any thought, or been inconvenienced, either because they always use RetroArch in one mode or the other, or didn't care to file a complaint.

Overall, insulting the design is not constructive. You can do better. RA is always growing, and we need your help to make it awesome. Would love your thoughts on where it could go and how it could improve. Thanks!

Meow. I think a bigger issue, is in Windows, when I run retroarch --help, I don't get a list of switches.

[m-7761]

Off-topic: Esc doesn't close Windows applications. You use Alt+F4 for that. People actually lose their mind when Esc closes applications. It closes inner pop-up screens. Not applications. EDITED: RetroArch does have a nonstandard UI, but Esc should be the same as Backspace. Its UI is pretty hellish with a keyboard. But it should not use Esc to close, even if it seems convenient.

[ghost]

Esc used to close applications way before Windows, it was quite common with Japanese computers and games and was modeled after that IIRC.

Anyone can remove/change the setting if they don't like it. But it has been discussed to death and the default won't be changing.

[m-7761]

@fr500 Good, that's one version ahead of the one on the website. Why not just add an another Fullscreen option then, to make RetroArch behave like every video player ever does? How hard can that be? And a --windowed switch at the same time. I don't think of RetroArch as a computer game, but more like a media player. I don't know how PC games work, but that is a very niche audience, and RetroArch games are mostly console games.

[m-7761]

I NOTICED THE TITLE CHANGED

First, "--fullscreen=false" is nonstandard. --windowed is a better way. (Unless this is an X11 thing.)

Second, see my previous post (please add a UI option to control fullscreen at startup. There are already so many options, and this will help people who fill like RetroArch is gaslighting them... after they've set Start In Fullscreen ON/OFF for the 10th time!)

[Tatsuya79]

Or disable settings -> config -> "save config on exit". It will stay on what you want for fullscreen then, disregarding if you're part of a niche audience or not.

[orbea]

I think a --windowed option is a fair request, the other suggestions are all much more complicated than required.

I took a quick attempt at this, but unfortunately it doesn't quite work. I'm not sure how to explicitly make RetroArch windowed instead of fullscreen, but regardless this diff should be a good start.

diff --git a/docs/retroarch.6 b/docs/retroarch.6
index c6bf53d93c..49e4cb79f1 100644
--- a/docs/retroarch.6
+++ b/docs/retroarch.6
@@ -84,6 +84,10 @@ Do note that save states are bound to the libretro implementation being used. Us
 B--fullscreen, -fR
 Always starts RetroArch in fullscreen. Disregards settings in configuration file.

+.TP
+B--windowed, -wR
+Always starts RetroArch windowed. Disregards settings in configuration file.
+
 .TP
 B--config PATH, -c PATHR
 Sets the configuration file path. BretroarchR will use this path to load the configuration file.
diff --git a/retroarch.c b/retroarch.c
index ccfe66dc9f..71726f871e 100644
--- a/retroarch.c
+++ b/retroarch.c
@@ -503,6 +503,8 @@ static void retroarch_print_help(const char *arg0)
    puts("  -S, --savestate=PATH  Path for the save state files (*.state).");
    puts("  -f, --fullscreen      Start the program in fullscreen regardless "
          "of config settings.");
+   puts("  -w, --windowed        Start the program windowed regardless of "
+         "config settings.");
    puts("  -c, --config=FILE     Path for config file."
 #ifdef _WIN32
          "
        Defaults to retroarch.cfg in same directory as retroarch.exe."
@@ -643,6 +645,7 @@ static void retroarch_parse_input_and_config(int argc, char *argv[])
       { "help",               0, NULL, 'h' },
       { "save",               1, NULL, 's' },
       { "fullscreen",         0, NULL, 'f' },
+      { "windowed",           0, NULL, 'w' },
       { "record",             1, NULL, 'r' },
       { "recordconfig",       1, NULL, RA_OPT_RECORDCONFIG },
       { "size",               1, NULL, RA_OPT_SIZE },
@@ -726,7 +729,7 @@ static void retroarch_parse_input_and_config(int argc, char *argv[])

    /* Make sure we can call retroarch_parse_input several times ... */
    optind    = 0;
-   optstring = "hs:fvS:A:c:U:DN:d:"
+   optstring = "hs:fwvS:A:c:U:DN:d:"
       BSV_MOVIE_ARG NETPLAY_ARG DYNAMIC_ARG FFMPEG_RECORD_ARG;

 #ifndef HAVE_MENU
@@ -887,6 +890,10 @@ static void retroarch_parse_input_and_config(int argc, char *argv[])
                recording_set_state(true);
             break;

+       case 'w':
+          rarch_force_fullscreen = false;
+          break;
+
 #ifdef HAVE_DYNAMIC
          case 'L':
             if (path_is_directory(optarg))

I think it just needs to be fixed under case 'w':.

[m-7761]

@Tatsuya79 That's trading one disadvantage for another.

@orbea Can you please look at saving/restoring the window's geometry, like most full featured Windows applications do. It seems like RetroArch is more than at a place where it should have professional grade polish.

When RetroArch starts on my desktop, it's always hidden behind the taskbar (vertical, on left side) and then clicking it, even in the nonclient area, behaves like navigating its menus. It shouldn't do that, especially when clicking the title bar, but it should also remember its geometry so it wouldn't be a problem to begin with. But also it must be doing something wrong, because the taskbar should not stay on the screen after RetroArch is started. So you have a basket of issues, all related to very unprofessional implementation of a basic Windows graphical application.

P.S. Another user here was almost livid with me because I did not know about the "Desktop UI" system, so maybe you guys should advertise these things better, by putting F5 in the window's menu, and also why not put \tF2 and \tF4 in the Save/Load State menus. These are basic amenities all Windows developers provide to users.

[inactive123]

Can you please look at saving/restoring the window's geometry, like most full featured Windows applications do. It seems like RetroArch is more than at a place where it should have professional grade polish.

This is maybe a fair point, and it would be nice if that could be done. On the other hand, I think you severely underestimate the work behind all of this. Dealing with raw Win32 is really not a lot of fun, especially not with this codebase. And if you implement it for Windows, you have to implement it for Linux too, then Mac, etc. Things are always a lot easier when you can rely on a dozen frameworks instead of having to write everything from scratch.

It's not that we don't want to do it, it's that we currently lack a developer interested enough to implement these things, since it's not as trivial as you think it is. You could maybe volunteer your services since you seem to care about this issue. By all means. As long as we are getting somewhere here. Just reiterating the same point over and over is going to get us nowhere. Let's get stuff done instead cooperatively, and that also includes stepping away from the notion that we as devs have to do all these things by ourselves. Some cooperation here could go a long way. The fact it has not been done so far should tell you something about either the willingness or availability of devs that would be keen to take something like this on. So if you can be that difference, then by all means.

P.S. Another user here was almost livid with me because I did not know about the "Desktop UI" system, so maybe you guys should advertise these things better, by putting F5 in the window's menu,

There is this button here now too to go directly to the Desktop UI. I don't know how much easier we can make this, or how much more spoonfeeding we can do here.

and also why not put \tF2 and \tF4 in the Save/Load State menus. These are basic amenities all Windows developers provide to users.

Please show us what you mean pictorally, it is very hard for us to even understand what you want here. And to be frank, you could just submit these suggestions to us in a PR if they are so basic.

[m-7761]

@twinaphex If you put "\tF2" after the text of a Win32 menu item, it will be displayed as a hotkey tip. This way the menus teach users how to use the keyboard instead. It's standard practice.

That icon is not in my RetroArch. Maybe it needs an Updater, especially because when I installed it, I was flabbergasted by the huge size of its download, and that makes it prohibitively difficult to update. I expected it to come with 200 emulators built-in going by its file size alone. (EDITED: I tried the "Online Updater" option in yours screenshot, however, I don't see how it can update RetroArch itself.)

[inactive123]

That icon is not in my RetroArch. Maybe it needs an Updater, especially because when I installed it, I was flabbergasted by the huge size of its download, and that makes it prohibitively difficult to update

What can I tell you, people want all sorts of fancy icons, backgrounds and whatnot, and complain when they're not there. Then when we include them, they move the goalposts and complain about filesize instead. It's never good enough, and there's always something to complain about.

Things are already as compact as we could make them. It would be far, far worse if we just interfaced against a bunch of dependencies like so many other projects. Qt libs doubtlessly add a fair something to the total size. This is unavoidable if we want to have a desktop UI. Take it up with Qt.

Also, 200MB is not a 'huge size' at all. I tried downloading the Instagram client for Windows, it was 200MB alone. I do think you are becoming a bit unfair and overbearing with your criticism of RetroArch in general, to be very frank. It's fine to be critical but a lot of these things you mention frankly I think applies to 90% of software in general nowadays, and if you don't want all these things that swell up the size, you can compile from source and bake out all these components that people actually wanted and requested. There are few projects where it's still so easy to bake out certain modules that you don't want. Give us credit where credit is due here.

(EDITED: I tried the "Online Updater" option in yours screenshot, however, I don't see how it can update RetroArch itself.)

The ability to update RetroArch itself is not available in XMB/GLUI/RGUI right now, you have to use the Desktop Menu for it.

Tools -> online Updater -> Update RetroArch.

[inactive123]

Some of the main culprits of the file size are the Qt 5 and ffmpeg libs. These are unfortunately the only dependencies we HAVE to interface against if we want to have a desktop UI and recording options. You could download the full version once, and then from there on out, download the version that comes without the big redist. The redist is what makes it big. I'm sorry but projects like Qt 5 and ffmpeg can tend to be rather big in filesize as static/dynamic libraries. We'd prefer if they were small too.

Biggest culprit is the assets, database files, etc. And still, these are still way more compact when you consider size and scope than most projects. There might still be some ways to cut down on it somewhat but it is what it is, if users want fancy visuals and presentation, they cannot then complain about the size either. It's either one or the other.

[orbea]

@orbea Can you please look at saving/restoring the window's geometry, like most full featured Windows applications do. It seems like RetroArch is more than at a place where it should have professional grade polish.

Sorry, I am not much of a programmer, I don't use windows and with a tiling window manager this use case is foreign to me...

[m-7761]

@orbea The geometry is just the position and size of the window that is standard with X11 or anything really. Users notice when every time they use an application they have to repeat the same things that can easily be automated. It's funny because developers typically streamline the experience for themselves, since they are the most affected users. RetroArch is far from streamline and there's no reason to become agitated or angry with users that point out the obvious. (@twinaphex It's not even criticism, just observation, and the courtesy to communicate that there are deficiencies at all. As a developer, I wish more people were vocal about deficiencies, and It may be that my awareness to the keen need for feedback prompts me to speak forthrightly about such matters. If I didn't care about RetroArch I wouldn't take the time to communicate these matters.)

In theory, not recording the position of the window is a bigger problem than randomly opening into fullscreen mode. The very easy solution is to provide options. Having an option to behave like a regular media player is not asking too much... having to customize a shortcut with command-line parameters is obviously asking too much from end-users. It must be trivial to set up a start up option. Just do it.

[dankcushions]

"easily be automated" "very easy solution"

you can only call something "easy" if you're prepared to do it. otherwise, you're being obnoxious, just like in your psx issue. i only help polite people. unfollowing...

[m-7761]

"easily be automated" "very easy solution"

you can only call something "easy" if you're prepared to do it. otherwise, you're being obnoxious, just like in your psx issue. i only help polite people. unfollowing...

It's as simple as dropping a name for a Yes/No Option into the video menu, and implementing a boolean check for the option at start up. And waiting for translations to trickle in. You're comments demonstrate immaturity.

[inactive123]

Let's keep the peace in here. Anyway, I think we more or less know now what you are requesting. Which leaves having somebody implement this. In case none of our core devs is available right now to do this, I might suggest going the bounty route.

[inactive123]

Hi there @mick-p1982 ,

I've started taking an initial stab at some of the suggestions you made.

https://github.com/libretro/RetroArch/commit/e1afdf8c3cf201e6481493c2cd98c12eecd02040

There is a new setting called 'Save Window Position' (will probably rename it to 'Remember Window Position'). Right now it's only implemented for Windows, and it stores the X/Y value of the window and uses them as default values when you next start RetroArch again.

Right now, it does only handle x/y. It does NOT handle resizing of the window or maximizing/unmaxizing it. So those parts I will still have to figure out.

Anyway, hopefully you like where this is going and I already wanted to keep you abreast of development, to show it has not been forgotten.

[inactive123]

Pushed another improvement -

https://github.com/libretro/RetroArch/commit/5313c50b0e14e45cfc29d72824b67d7faf60f22a

It now saves/remembers the size of the window too.

There is still one odd edge case that we might need to figure out how to fix - when clicking maximize button - you need to then move the window slightly in order for x/y position to be saved - just clicking maximize alone is not enough

[inactive123]

I have noticed a slight regression - windowed scale no longer scales properly. I'll have to look into that tomorrow.

This is really the problem with all these feature requests - people are ignorant to the fact that the RetroArch codebase really is not set up well enough to just make subtle changes like this and all the codepaths magically work out. Lots of covering of edge cases is needed which makes adding these kinds of features a tremendous chore. Far better to just decide not to do certain things for the sake of simplicity.

In any case, here we are, and I'm committed to sorting this out, so we'll see how it goes.

[inactive123]

Windowed scale seems to work properly again if you turn off 'Remember window positions'.

So an alternative could be that we just tell people to turn this setting off ('Remember window positions') if they want to use windowed scale, but that would simply be working around the current bug/issue. It will depend on the complexity of the issue at hand and how difficult/easy it would be to workaround it/solve it.

[m-7761]

There is still one odd edge case that we might need to figure out how to fix - when clicking maximize button - you need to then move the window slightly in order for x/y position to be saved - just clicking maximize alone is not enough

Normally fullscreen/maximize doesn't count as a window's position or size, since A) it's pretty pointless, and loses the restoration information, and B) the position is 0,0 and the size cannot be obtained from any other position.

Something that makes me nervous about RA is I don't know who (or what) is in control of the initial size of the window. I assume that the emulator chooses an appropriate size, by default. Whatever the case may be, if the window is manually resized, via the frame, it's unclear how to get back to that default size. All I'm saying, is maybe the Restore button should be enabled after manually sizing the window, so it can be used to get back to the default/recommended size.

In RA's case, storing only the position might not be a bad idea. Unless the size is saved for particular games/cores it seems like its size is always shifting, and so maybe it's not as important as just getting the window to open at the same location.

In any case, the problem with opening to fullscreen, can be solved by just not counting maximize/fullscreen as the position of the window. That would mean it would always remember the window position, and open to that, instead of wiping it out with 0,0 every time it goes to fullscreen modes.

EDITED: Thanks of course!

P.S. Off-topic, but speaking of remember states, I had a bad time the other day with a feature that actually overwrites the Save folder when a save state is loaded. I think that feature needs to be hard OFF by default, or have a mode that distinguishes between cartridges with batteries and external storage like memory cards. https://github.com/libretro/beetle-psx-libretro/issues/175 I think this corrupts the memory card files. I don't imagine they are restored when the game is turned off. I just think this is a really horrible design. A PlayStation memory card has absolutely nothing to do with a save state. Sorry to drop this here, but I just want to mention it without further discussion. I believed the memory card software I was using couldn't write a valid memory card, because this RA feature seems like something that would never occur to anyone. I mean, anyone who has ever used a PlayStation. It's just counterintuitive. These things hurt people en mass. The developers that institute them don't appreciate the thousands of hours of anguish they are inflicting on hundreds or thousands of people :)