melonDS
melonDS copied to clipboard
melonDS-emu
Slot-2 addon support (v1.0)
This pull request adds support for the DS Rumble Pak (packaged with Metroid Prime Pinball, compatible with several DS games), the Guitar Grip (required for the Guitar Hero: On Tour games), and the DS Memory Expansion Pak (required for the DS Browser).
Located in the emulator settings dialog is a drop-down menu (below the "Console type" drop-down) for choosing the desired Slot-2 addon. The "Rumble Pak" option emulates the DS Rumble Pak, the "Guitar Grip" option emulates the Guitar Grip used by the Guitar Hero: On Tour games, the "Memory Expansion Pak" option emulates the DS Memory Expansion Pak, and the "None" option emulates no Slot-2 addon.
The Guitar Grip implementation comes with assignable hotkeys for the Guitar Grip's four colored buttons, which can be configured in the "Addons" tab of the input config dialog.
I intend on solving most, if not all, of the add-on related issues in mainstream melonDS, which is why this proposed Slot-2 add-on implementation constitutes the initial version of many. As such, if this pull request is merged, expect support for more add-ons, such as the "Tony Hawk" motion pak, the "Slide Controller", and others, to be added in future versions.
I'm opening this pull request early for any feedback related to coding style and UI design.
Here is a demo of the Memory Expansion Pak implementation:
https://drive.google.com/file/d/1l1PTeNzFacDgqN5hr5-PmjXi2T_rE_iu/view?usp=sharing
Demos for the other emulated add-ons are available upon request.
skimmed over it and looks good to me
@rzumer do you have some thoughts on this?
One thing I'd like to ask before I get around to reviewing the actual code is to squash formatting fixes into their relevant commits (or fix them "pre-emptively" in an interactive rebase).
Also for reference, this closes #99, #73, and #384.
Sure, I'd be happy to squash the formatting fixes into their relevant commits! The fixes should be done within the next few hours!
Alright, it's past 9 pm where I live right now. I'll continue work on this PR tomorrow, okay?
In the meantime, I'll temporarily mark this as a draft and work on fixing the remaining issues over the next few weeks, if that's okay with you...
While this makes the Guitar Hero games reach in-game, they're still not very playable (at least not in a confortable way). You need to strum on the guitar (center of the touchscreen) for each note, so you need to hold the note button with a key (or a button on the controller) while making the touch gesture with the mouse... really weird to play like this (and certainly 100% impossible to play any song on hard as you need to strum really fast).
One possible solution to cover at least all the Guitar Hero games: shortcut to key/buttons for the touchscreen motion needed, so you can play it properly with both controllers and keyboards
Agreed, this was the first thing that came to mind as a "dirt quick" fix. As an actual solution (or at least close to it), Citra latest report came to mind with their mentioned "Touchscreen Mappings". Details here https://github.com/citra-emu/citra/pull/5163
thanks for the reference, that's certainly interesting. The Switch frontend already has some analog stick -> touchscreen mapping options, which I want bring over to the main repository.
it's because that commit made change which are in conflict with those of this PR.
Seems the other branches don't like this one, recent build again Slot-2 addon support is gone.
There are still some unresolved comments, make sure to expand collapsed discussions. You should be able to mark ones that were dealt with as resolved to collapse them by default.
Alright, just resolved most of the unresolved comments. I'm still waiting on the rest until we have more information on those fronts. Hope this gets merged soon!
I think I know why the Ubuntu aarch64 build is failing. It's because of an installation issue with the grub-efi-amd64-signed package. I have no idea what's causing that error, so if anyone has any ideas as to why that's the case, please let me know!
what still bugs me, is that your changes aren't really integrated @rzumer's previous slot-2 work. It would probably be the best if the solar sensor and the gba cart were integrated into your scheme of slot2 additions (both from the code, but also from the UI).
That opens of course more questions, the solar sensor for example is automatically inserted for the associated games. Should that be performed with other peripherals as well? Yesterday we also had some discussions about refactoring Slot1 and Slot2 devices as polymorphic classes.
Please tell us what you think! If you want to do it, should further refactorings go right into this PR or be made with separate one?
That opens of course more questions, the solar sensor for example is automatically inserted for the associated games. Should that be performed with other peripherals as well?
I think you're conflating the GBA cartridges that enable the sensor controls when inserted, and the DS card that samples the sensor. There's no sensor "inserted" with the DS card alone. Detecting GBA cartridges that can vibrate and enabling rumbling when they are inserted would be another example of that. In most cases it doesn't make much sense to automatically insert a peripheral based on the DS card.
I think you're conflating the GBA cartridges that enable the sensor controls when inserted, and the DS card that samples the sensor. There's no sensor "inserted" with the DS card alone. Detecting GBA cartridges that can vibrate and enabling rumbling when they are inserted would be another example of that. In most cases it doesn't make much sense to automatically insert a peripheral based on the DS card.
oh sorry, you're right. Also good point regarding GBA games which can rumble, so ideally Slot-2 peripherals and GBA games should be separated (from a code standpoint, so that the functionality can be reused).
oh sorry, you're right. Also good point regarding GBA games which can rumble, so ideally Slot-2 peripherals and GBA games should be separated (from a code standpoint, so that the functionality can be reused).
I think so too, but a GBA cartridge is still a slot-2 device, so it's not intuitive for it to be separated from the others in the interface.
I think I know why the Ubuntu aarch64 build is failing. It's because of an installation issue with the grub-efi-amd64-signed package. I have no idea what's causing that error, so if anyone has any ideas as to why that's the case, please let me know!
@Buenia0 fixed this with PR #764.
Just as a reminder there are still unaddressed issues:
- Slot-2 cartridge type is still hardcoded integers only defined in a comment, should be enum values
- GBA cartridges are still separate from all other slot-2 cartridges, which leads to unintuitive/confusing behaviour
how do you want slot-2 stuff to be "merged"? like a drop down menu the emu settings menu where you can choose between using a gba rom or a slot 2 accessory?
My idea for a first implementation would be something like that, but I'm open to alternatives.
- GBA cartridge as an option in the slot-2 dropdown
- GBA cartridge either settable from the settings menu, or cartridge type set to GBA automatically when a new GBA ROM is successfully loaded from the Open... menu or drag-and-drop, with an OSD message to reflect that
- GBA cartridge/ROM unloaded/reset if it is swapped for another peripheral
This reminds me slot-2 cartridge type should be stored in save states if it is not there already.
how do you want slot-2 stuff to be "merged"? like a drop down menu the emu settings menu where you can choose between using a gba rom or a slot 2 accessory?
yes, correct me if I'm wrong, but I think currently you can select both a gba rom as well as a slot 2 peripheral at the same time and it's only a matter of how the things are ordered in the code what will happen.
Just as a reminder there are still unaddressed issues:
- Slot-2 cartridge type is still hardcoded integers only defined in a comment, should be enum values
- GBA cartridges are still separate from all other slot-2 cartridges, which leads to unintuitive/confusing behaviour
Currently working on resolving those right now, rzumer! Should have something ready soon!
@rzumer Are all values in GBACart(_SRAM)::DoSavestate actually used? I've been reworking GBACart trying to fit it in with the rest, but I can't fully wrap my head around the save states.
