Open fpiesche opened 1 week ago
There is the SDL version, which is different from the QT version which has an interface
Yeah - thus in the current setup, a user would need both the SDL and the Qt version installed to be able to direct-launch games without waiting for the game list to populate first, but also have the GUI available for configuration. Making the Qt version skip the GUI, or at least the game list read, when launching an executable directly, would improve QOL for users of the Qt version.
I'll admit I haven't actually used the SDL version; does it meaningfully differ from the Qt version once it gets to actually running a game, e.g. in terms of Wayland support etc?
The QT version didn't even have a command, I remember that I was the one who added the ability to run the game through the command line in the QT version, just like in SDL, I did this just to be able to create game shortcuts correctly. It's a good idea to have a command to run QT headless, similar to SDL.
It'd be useful if the main Qt GUI executable didn't bother trying to read the entire game directory when it's launched directly into a game (by calling
shadps4 path/to/eboot.bin
). Some emulators just do this transparently, others (eg. RPCS3) have a command line flag to disable running the main GUI (in RPCS3's case,--no-gui
).This will make the emulator useful for configuring via the GUI when running it directly with no parameters, while also allowing the same executable to launch into a game directly without having to wait for the game list to build on startup first. This is a common use case with game launchers such as Steam's game mode or things like Launchbox and Playnite.
Ideally this should also launch in fullscreen mode, though doing this could also be handled by a separate command line parameter (that is, just running
shadps4 eboot.bin
will run the game in windowed mode, while runningshadps4 --fullscreen eboot.bin
will launch it in fullscreen).