Subsystem implementation for the Game Boy Player.#453
Draft
replicacoil wants to merge 1 commit into
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
@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);tostd::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:
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.