Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify SGB related UIs and make it possible to use SGB under Gambatte link #3635

Open
wants to merge 28 commits into
base: master
Choose a base branch
from

Conversation

Fortranm
Copy link

@Fortranm Fortranm commented Apr 16, 2023

This is a revision of #3283 made to work on BizHawk 2.9.

https://en.wikipedia.org/wiki/Super_Game_Boy#Super_Game_Boy_2

The Super Game Boy 2 was released exclusively in Japan in 1998. Additions included a link port to allow a user to access two-player mode via the link cable...

Currently, the SGB mode of Gambatte has to be turned on via Config > Cores > GB in SGB instead of in the sync setting and cannot be used in GB Link as a result.

This PR does three things related to SGB:

  1. SGB is added (or rather, merged in) as a Console Mode option for Gambatte.
    image

  2. "GB in SGB" check box and SGB core picker are removed and the BSNES cores are added under the GB core picket (legacy BSNES core not included). GB/GBC games will load under SGB mode of the corresponding BSNES core if one of those options are chosen.
    image

  3. As a result of the first change (with addition adjustments), it is now possible to use SGB mode in Gambatte Link too.
    image
    image
    image
    image
    Each SGB core can have up to 4 controllers linked to it. The Power button for each SGB core is included on the first Player tab of the core for the time being.
    Note that the tab parsing process is currently hardcoded to categorize every item that starts with "Px " under the tab "Player x" and everything else under "Console". There have been suggestions to use "Console x" for a core in link mode but that requires enough refactoring to be considered a separate task IMO.

Note: The SGB sound is not implemented yet but that can be done along with the MBC sound fix for Gambatte Link altogether later.

resolves #2289

TiKevin83
TiKevin83 previously approved these changes Jul 12, 2023
Copy link
Contributor

@TiKevin83 TiKevin83 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

approving from a code perspective, haven't done a QA of the functionality yet

src/BizHawk.Client.Common/RomLoader.cs Outdated Show resolved Hide resolved
src/BizHawk.Client.Common/config/Config.cs Outdated Show resolved Hide resolved
src/BizHawk.Client.Common/movie/import/LsmvImport.cs Outdated Show resolved Hide resolved
Copy link
Collaborator

@Morilli Morilli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haven't tested the gambatte changes extensively but I think this is solid enough to get in. The "gb as sgb" UX flow was pretty bad imo so this is a definite improvement.

Copy link
Member

@YoshiRulz YoshiRulz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm curious of what @CasualPokePlayer has to say, specifically about the video buffer stuff. But this now LGTM in terms of code. (I think you deserve some kind of trophy for hacking together the button mapping by doing it in the wrong direction and with 3 nested loops.)
As for functionality, opening a 4x bundle and immediately closing it results in:

stacktrace
System.NullReferenceException: Object reference not set to an instance of an object
  at BizHawk.Emulation.Common.LinkedSaveRam.CloneSaveRam () [0x0002f] in <f3a4da15026e4f05ab7072e9a135677c>:0
  at BizHawk.Client.EmuHawk.MainForm.FlushSaveRAM (System.Boolean autosave) [0x000f0] in <5e7f3991f9b246bb80e8d9725eda76e1>:0
  at (wrapper remoting-invoke-with-check) BizHawk.Client.EmuHawk.MainForm.FlushSaveRAM(bool)
  at BizHawk.Client.EmuHawk.MainForm.CloseGame (System.Boolean clearSram) [0x0006f] in <5e7f3991f9b246bb80e8d9725eda76e1>:0
  at BizHawk.Client.EmuHawk.MainForm.CloseRom (System.Boolean clearSram) [0x00010] in <5e7f3991f9b246bb80e8d9725eda76e1>:0
  at (wrapper remoting-invoke-with-check) BizHawk.Client.EmuHawk.MainForm.CloseRom(bool)
  at BizHawk.Client.EmuHawk.MainForm.CheckHotkey (System.String trigger) [0x01588] in <5e7f3991f9b246bb80e8d9725eda76e1>:0
  at BizHawk.Client.EmuHawk.MainForm.<ProcessInput>b__143_0 (System.Boolean current, System.String trigger) [0x00000] in <5e7f3991f9b246bb80e8d9725eda76e1>:0
  at System.Linq.Enumerable.Aggregate[TSource,TAccumulate] (System.Collections.Generic.IEnumerable`1[T] source, TAccumulate seed, System.Func`3[T1,T2,TResult] func) [0x0002e] in <89a8dc5bc33447a4a98f23a2d52e8aee>:0
  at BizHawk.Client.EmuHawk.MainForm.ProcessInput (BizHawk.Client.Common.InputCoalescer hotkeyCoalescer, BizHawk.Client.Common.ControllerInputCoalescer finalHostController, System.Func`2[T,TResult] searchHotkeyBindings, System.Func`2[T,TResult] activeControllerHasBinding) [0x00135] in <5e7f3991f9b246bb80e8d9725eda76e1>:0
  at BizHawk.Client.EmuHawk.MainForm.ProgramRunLoop () [0x0009c] in <5e7f3991f9b246bb80e8d9725eda76e1>:0
  at (wrapper remoting-invoke-with-check) BizHawk.Client.EmuHawk.MainForm.ProgramRunLoop()
  at BizHawk.Client.EmuHawk.Program.SubMain (System.String[] args) [0x0042b] in <5e7f3991f9b246bb80e8d9725eda76e1>:0

@Morilli

This comment was marked as resolved.

@YoshiRulz

This comment was marked as resolved.

@YoshiRulz
Copy link
Member

YoshiRulz commented Jun 1, 2024

I still don't have a nice repro, but I found the culprit with print-debugging, and it wasn't related to this PR. Pushed 64db1fe.
In working on that, I've seen that SGB in GambatteLink is working, so I won't block this any further. @CasualPokePlayer?

@@ -22,8 +22,7 @@ public partial class Gameboy : IInputPollable, IRomInfo, IGameboyCommon, ICycleT

[CoreConstructor(VSystemID.Raw.GB)]
[CoreConstructor(VSystemID.Raw.GBC)]
[CoreConstructor(VSystemID.Raw.SGB)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is SGB being removed here? BSNES/BSNESv115 still have it.

Copy link
Collaborator

@Morilli Morilli Jun 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because for core choosing, the system is only set to SGB when the core is bsnes:

static bool IsPreferredCoreSGB(Config config)
=> config.PreferredCores[VSystemID.Raw.GB] is CoreNames.Bsnes or CoreNames.Bsnes115 or CoreNames.SubBsnes115;
if (IsPreferredCoreSGB(_config))
{
game.System = VSystemID.Raw.SGB;
}

Thinking about it, that's probably logic that could get removed too...

Copy link
Member

@CasualPokePlayer CasualPokePlayer Jun 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does this exactly end up working for say, loading a GBC only ROM into BSNES. Does it proceed to fail completely due to not finding a fallback with the SGB system ID ctor, or does it end up still picking Gambatte with the GBC system ID?

Copy link
Collaborator

@Morilli Morilli Jun 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point. It does NOT work currently for that exact reason and instead runs into this code which then no longer makes sense:

DoLoadErrorCallback("Failed to load a GB rom in SGB mode. You might try disabling SGB Mode.", system);

This comment was marked as duplicate.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's more to this, and there is already broken behavior currently. I'll make an issue later.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#3960
The new issue in question for reference. The way this currently is makes sense with that proposed change.
Resolving.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not resolved.

Fortranm and others added 2 commits July 1, 2024 12:04
This fixes failures in CorePickerStabilityTests (https://ci.appveyor.com/project/zeromus/bizhawk-udexo/builds/50119675). It's not necessary to put SGB there as the system id is only ever switched to SGB after a relevant core is already initiated.
quicknes/core Outdated Show resolved Hide resolved
[CoreConstructor(VSystemID.Raw.Satellaview)]
[CoreConstructor(VSystemID.Raw.SGB)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keep this attribute...

[CoreConstructor(VSystemID.Raw.Satellaview)]
[CoreConstructor(VSystemID.Raw.SGB)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...and here...

@@ -21,8 +21,7 @@ public partial class Gameboy : IInputPollable, IRomInfo, IGameboyCommon, ICycleT

[CoreConstructor(VSystemID.Raw.GB)]
[CoreConstructor(VSystemID.Raw.GBC)]
[CoreConstructor(VSystemID.Raw.SGB)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...and here...

@@ -22,7 +22,8 @@ namespace BizHawk.Emulation.Cores.Nintendo.SNES
public unsafe partial class LibsnesCore : IEmulator, IVideoProvider, ISaveRam, IStatable, IInputPollable, IRegionable, ICodeDataLogger,
IDebuggable, ISettable<LibsnesCore.SnesSettings, LibsnesCore.SnesSyncSettings>, IBSNESForGfxDebugger
{
[CoreConstructor(VSystemID.Raw.SGB)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...and here.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At the very least this one is questionable as the core doesn't ever actually sets its SystemID to SGB. I don't really mind this too much, but I do think we should be able to agree on what this attribute is supposed to mean.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Semantically, it indicates which constructor to use for a given RomGame.
Also, the set across all of the core's constructors doubles as the list of sysIDs which that core can emulate. We could split that out to the [Core] attr instead, but I think a single-source-of-truth is better.

if (game.System == VSystemID.Raw.SGB)
{
IsSGB = true;
SystemId = VSystemID.Raw.SNES;

^ This is clearly incorrect. I imagine it was a hack to get the frontend to show the right menus/tools.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the set across all of the core's constructors doubles as the list of sysIDs which that core can emulate.

This is precisely the issue; I don't think this invariant necessarily needs to hold true (it doesn't even right now with that old bsnes core), and even with your suggested change bsnes* core cannot provide the GB/C SystemID, even though they have a corresponding CoreConstructor attribute.

That attribute is currently entirely internal and only used for the internal selection process of which cores to consider for a given rom, so putting semantic stuff here that is supposed to communicate meaning to the reader while doing nothing for the core or romloader that's using it is misguided imho.
It's fine to communicate this SGB stuff with a comment, but the attribute itself doesn't need to be here.

The conceptual question here is whether it is acceptable for a core to load a rom of type X and declare a SystemID of type Y != X using that loaded rom, and I say yes.

Copy link
Member

@YoshiRulz YoshiRulz Jul 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about this:

  • RomLoader never sets SGB on any rom (since any GB rom could be used with SGB, they should all be detected as the same, and GB/GBC is the better choice)
  • There is no core preference for SGB, only GB and maybe GBC
  • Cores are perfectly honest with setting IEmulator.SystemId (not necessarily matching the one passed in, since a sync setting can choose between GB/GBC/SGB)
  • SystemId always matches a [CoreConstructor]—if it doesn't make sense to have that ctor, like with SGB which RomLoader will never use, it can simply be private and call something like this(default)

I think that would give the consistency I'm after while being simpler for regular users.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The first three should already be present here.

If you feel like adding dummy constructors with the SGB attribute just to signal intent, fine.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The first 3 are not already implemented. This PR addresses some of them, but I'm saying we should clean it up on master first.

Copy link
Author

@Fortranm Fortranm Jul 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The first 2 definitely are included in this the PR.
The only one that doesn't currently fit 3 is the legacy BSNES core. Actually modifying that core to use the SGB sysID should be a separate task imo (and hopefully the core is retired before that has to be done, maybe)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Switching to/from SGB is unintuitive
5 participants