Subsystem implementation for the Game Boy Player.

[replicacoil]

@cscd98 Would you mind taking a look at my PR and give feedback before I remove the draft flag? I believe you are the maintainer of this core now and feedback of the decision would greatly help getting it over the finish line.

This is an implementation of the Subsystem menu of Retroarch for the Game Boy Player in the Dolphin Emulator core.

It has a simple menu under 'Load Content' to select both the ROM and the GBPlayer disc in order to play the GB\GBC\GBA game on a Game Cube similar to how bSNES does it with the Super Game Boy.

The ROM is set to be the primary content and the GC disc as secondary as per the guidelines of Retroarch.

There are 2 points that do need to be discussed:

• This core now saves 2 types of content instead of one. A ROM save for the game played as well as a User directory with GC save for the settings of the Game Boy Player. If sorting is enabled, the ROM save will simply use the settings to set that path correctly as it is the primary content. If nothing is done, the GC save will end up there as well and I try to address it in the DolphinLibretro\Boot.cpp. I understand that I am trying to solve frontend issues in a core, but currently there is no other way to have both saves end up where they should as the Subsystem currently only provides 1 save path and since this is a multi-system core, it is not too farfetched to think that users have set save sorting enabled for it.

• In HW\GBACore.cpp I have edited the save location line from
  std::string save_path = fmt::format("{}-{}.sav", rom_path.substr(0, rom_path.find_last_of('.')), device_number + 1); to std::string save_path = fmt::format("{}.srm", rom_path.substr(0, rom_path.find_last_of('.')));
  The reason for that is so that the GBPlayer reads the save files of the mGBA core as dolphin implemented mGBA as their emulator for GB\GBC\GBA content. I understand that this changes source code in the actual emulator instead of the Retroarch implementation of it but I see no other way to make it read *.srm saves the mGBA core makes. It is only one line and provides real benefit as by doing this, Retroarch provides a way to play GB\GBC\GBA ROMs through all types of Game Boy hardware:
  GB,GBC,GBA,SGB,SGB2,GBP with complete save compatibility. This in my opinion is the true value that Retroarch provides over standalone emulators. If there is a way to implement *.srm save compatibility from the Retroarch side of things, please provide guidance for it. No conversion is needed from the change of *.sav to *.srm in these cases as they are identical.

While testing do note that there is a bug with the Subsystems in Retroarch. When loading Subsystem content through the Retroarch menu that is not in an archive, content directory and game specific overrides do not get applied. This is because the field that sets the content info is not filled by the time it is requested in Retroarch\runloop.c. This was tested in bSNES with SGB and the issue is prevalent there as well. The issue with the bug is that if a user has content directory overrides for their system folder, the GBPlayer will not boot at all as it cannot find the *.ini to set the hardware even when the user has done everything correctly setup wise. Here are 3 runs of the dolphin core with Subsystems implemented, one run with the stable release, one run with the latest code and one run with the edit provided below. Note that these bugs are not in question when loading from CLI or when loading an archived ROM with a default bios location (in the case of bSNES).
Edit.log
Latest.log
Stable release.log

This should fix it, add it in Retroarch\runloop.c, function: runloop_event_init_core, around line 4881:

if (!sys_info->info.valid_extensions)
   strlcpy(sys_info->valid_extensions, DEFAULT_EXT,
         sizeof(sys_info->valid_extensions));

   //Add this line right here
   content_set_subsystem_info();

#ifdef HAVE_CONFIGFILE
   if (auto_overrides_enable)
      config_load_override(&runloop_st->system);
#endif

The thing is, since this is a front end bug and not a dolphin core bug, I am hesitant to push it as this will cause loading behaviour change for all cores using the Subsystem menu in Retroarch which in turn will have a lot of edge cases + users may already have working solutions build around it which could also break by it.

All in all, it really wasn't as easy as I hoped it would be but I do hope we can get this up and running in the core and let people play GBPlayer in Retroarch.

[cscd98]

Thanks for your patience! I've only skimmed the code (super busy) but looks fine to me. I tested it locally playing a couple of Wii and GC games (I don't have GB games to test). So as long as it doesn't break anything I'm fine with it.

[replicacoil]

Great, thanks for the feedback. As of now, I did not add *.dol files to the list of acceptable extentions of selectable Gamecube applications to launch with the subsystems because the Game Boy Interface homebrew application causes massive slowdown while the official GBP boot disc does not have these issues. I have tried to debug it but could not pinpoint the issue at hand.

[cscd98]

Oh yes could you put a #ifdef __LIBRETRO__ around the Source/Core/Core/HW/GBACore.cpp change? As it might get overwritten when I next update.