Open sevdestruct opened 6 years ago
Certain games on certain systems are going to require different sets of combo's, if that's the way to go.
Honestly this could all be solved by just adding a custom controller mapping setting per core that supports combos. It's not a difficult feature to write, but it would be time consuming and tedious since you'd have to go into all of the current cores and re-write how they handle events. There's not a consistent protocol that they all follow. Plus adding UI, even if somewhat basic.
I mean, this will probably come but no one is exactly raising their hands to write it either. We don't even have CD switching support wired up yet, which is something I recently promised to do.
I'm just saying I wouldn't spend too much time coming up with bespoke customisations when a more generic solution would be the preferred and best option.
That being said, there's no reason why you can't make your own build with your own mapping the way you want.
For PSX for example, on each frame it scans the state of the buttons on a controller.
You could edit MednefenGameCore.mm
- (NSInteger)PSXcontrollerValueForButtonID:(unsigned)buttonID forController:(GCController*)controller
(You can see just how much MFi code there is for just in Mednafen alone.)
You could change the code there to respond to combos.
Let's say you wanted leftShoulder and X to be select. You would do something like,
- (NSInteger)PSXcontrollerValueForButtonID:(unsigned)buttonID forController:(GCController*)controller {
if ([controller extendedGamepad])
{
GCExtendedGamepad *pad = [controller extendedGamepad];
GCControllerDirectionPad *dpad = [pad dpad];
// First determine if any desired combos are active before
// moving on to individual buttons
BOOL selectCombo = [[pad leftShoulder] isPressed] && [[pad buttonX] isPressed];
switch (buttonID) {
// ... bunch of cases
case PVPSXButtonL1:
return [[pad leftShoulder] isPressed] && !selectCombo;
// && !selectCombo is to ignore standard left shoulder if a combo is pressed, or maybe not use
// it at all unless you have to start using delays or press them both on the same frame
case PVPSXButtonSquare:
return [[pad leftShoulder] buttonX] && !selectCombo;
// Again, see comment above on why this would be tricky with frame accuracy
case PVPSXButtonSelect:
return selectCombo;
// ... Rest of the cases and function
}
You have to also handle what happens if X is already pressed and the combo button is pressed, you have to decide if you want to act as if that's the same as letting off X, in which case the code above works, or if you want X, the non combo action, to stay pressed, you have to now store the fact that it's pressed so PVPSXButtonSquare
still returns true on each frame even though the combo is pressed, and then returning 0 when wither the combo initiator (left pad) or X is depressed.
See how it gets tricky really quick. Now do that for each system you want... gets out of hand. Best off just making a generic solution.
Another idea I had was to use https://github.com/robreuss/VirtualGameController and make something out of an Arduino (or raspberry PI which would be easier but those have to boot up), USB hub and send game commands over ethernet. I think it should be just as fast or faster than MFi bluetooth if both your Apple TV and the Arudino are on ethernet. I'm assuming this would be an ATV solution since you wouldn't have a portable solution, then again MFi controllers aren't really an on-the-go size device either. I have USB NES, SNES, Sega, N64 controller clones that are all standard class compliant Usb joysticks.
Another similar option would be to make something that took USB joystick commands in and sent USB keyboard commands out, piggy backing on the current iCade hack which is basically just faking a keyboard as using 'key stokes' as controls. I'd have to find a dev board that has both USB host mode and a bluetooth stack that isn't a nightmare.
I could actually probably prototype that using a Mac as a USB to Bluetooth keyboard dummy, but that would require making some kind of bluetooth app on OS X, and CoreBluetooth isn't a fun API to work with.
Either way, this would also require a custom mapping feature, since each controller will send different commands, but this would be a hell of a lot cooler than combo buttons, or worse, systems like Sega that have rows of 3 buttons across and are awkward no matter how you map an MFi controller in all the current models out there,
While it would be pretty awesome to have an arduino powered forwarder that would allow any controller to work, I wouldn’t expect many people to actually make that much effort. 😬
Well yes and no. Something like an Arduino is cheap as hell, and just requires plugging in a USB cable and flashing the program onto it. It's dumb simple from Mac or Windows since they have an app for both.
If we made it as simple as, buy this $25 Arduino board, flash this firmware, plug in USB controller and ethernet and it works, then I could see it being used by people. Of course the simpler you make it for other the more work it is on devs. This is something I really want to work on anyway because I have a few different models of Arduino development boards laying around for a long time now I need to put to use, though this would be another "down the line" thing for me, over extend as it is enough.
Since VirtualGameController already has host device code that runs on OS X, it would be pretty simple, I think, to write a prototype using a Mac.
Yes, you could just use OpenEMU if you have your Mac on hand, but you either have to AirPlay to a big screen (way too much lag) or pop out an HDMI cable, or worse if you have a new MacBook Pro like me you need a USB-C to HDMI adapter on top of that.
USB clones of various controllers are bountiful and cheap online, and I assume most people who have Apple TVs already have a Mac laptop at home too. Anyway, I think this would be way way way less effort than an embedded system.
A Raspberry Pi could be a compromise. Still cheap, portable, multiple USB ports and ethernet already on them, and could program it in Perl or something easy. They're cheap and low power enough that you could just leave one connected near your TV all the time with the controllers all hooked in and ready to go whenever without having to worry about booting up the Linux OS on them each time.
I definitely think you’re over-estimating the combined Venn diagrams that are:
😂
You’ve already seen how many people here download & install the app using the pre-built binaries or from iEmulators and stuff because they either have no idea how to compile the app, don’t have a mac or simply can’t be bothered with the effort.
I’m not saying don’t do it, it sounds like an awesome project — but I don’t think it’s a real solution to the controller issues we have.
With MFi there doesn't seem to be any real solution though. It's either combo buttons or deal with it until Apple, unlikely, expands the MFi capabilities.
Another idea, Apple TV only again, is to tape the Apple TV remove to the back of an MFi controller and use the gyroscope data. Tilt left for Select, Right for start, throw it on the ground and the system restores your previous auto save 😂😂😂
Haha, inventive 😬
I agree with James, i'd wager the amount of people who are willing to go the full on route of setting up the arduino route is slim. Like a small subsect of a subsect which is us.
About the Apple Remote idea, let's just engineer a custom module for that that snaps onto the back of various controllers like Nimbus and such, and throw together a Kickstarter campaign for it. I'll help us market it. Hell, I have a Leap motion dev kit mounted on the front of my HTC Vive HMD. why not this, haha.
However, on the idea of customized input, per core, or per game.. I have something in mind that might help us get the UI there quicker than say drawing custom skeuomorphic renders of all the controllers. It's in my list. But this plus some bespoke support for the most favored controllers is probably the way to go. Need to make it easy.. and stupid proof… cut down on all these issue posts rolling in, no? can you imagine getting more posts just around some wiki topic of rigging parallel hardware/software communicating to the app(s) externally..
Well the lovely thing about an Arduino is there is nothing to setup, you just flash the firmware. I mean, I plan to do it for myself, couldn't care less if anyone else wants it. And until someone comes up with a better solution, it's deal with MFi or use combos.
"Hey Siri, press L3" I think is the solution we can all agree on.
"Hey Siri, press L3" I think is the solution we can all agree on.
Hah. :)
@JoeMatt I think you're right, this is best with the button customization/mapping (#56) layer supporting combos.
That said, I'm updating the original ticket based on the above, and revising it with a new idea for the N64 C buttons that I think works much better.. I'd like to propose the revisions as a defaults set in the custom mapping, instead of a bespoke combination hardcoded.
Update: N64 Swap Mode / C-Mode portion of this now complete.
Update: PSX: MFi+ Mode portion of this ticket is now implemented / complete.
(Now referring to these additions as MFi+ Mode
)
I've been playing around the PSX mednafen interfacing code to try and get some of the games more playable when using an MFI controller.
I think the "analog mode" works perfectly fine as a menu item. Its something you toggle once per game. No biggie.
Select/Start can work as menu items although I prefer to use them as onscreen buttons as I'm using a gamevice.
The real problem (no shock to anyone) is L3/R3.
Other than the proposed, "Don't use MFI!" go via ardunino, I'm not sure they'll be any workable solution for some of the affected games using external controllers.
If using a gamevice the games affected can be playable (although clunky) depending upon the placement of the overlay buttons for L3/R3.
For example, in Ape escape: L3 is used to dive under water and you are meant to be using the left analog stick while diving. This means it has to be on the right to use it them together. R3 is used to fire a net underwater, this could work on the right or left.
In Wing Commander 4 R3 is used to boost and needs to be pressed at the same time as using the left analog stick. So again needs to be on the right.
I'm going to try a layout of Select/Start buttons being on the left and L3/R3 buttons on the right. I suspect though that depending upon the game you might need to be able to make their location configurable.
As for using key combos for these. I think in a lot of cases its not going to work because the buttons aren't always just a single click. A lot of the time they require the user to hold them down while doing other things.
In fact as I mentioned in a pull request the key combos actually break some games entirely like wing commander 3/4 which uses its own key combos. I think we need an option to disable them.
Curse Apple for MFI controllers rather than accepting a standard that has been around for 20 years.
I guess this leads me to following thoughts :
Just to be sure because I try it for 30min now : for PSX start and select are implemented but not L3 and R3 ? Start select work well but I try to press L1+L2+R1+R2 and down on left pad but nothing happened (on ape escape).
@leolelego they are, refer to the control mapping doc we set up linked in the wiki: Controls - there is still work to be done to improve how this works and feature is in an early phase right now.
In response to the discussion in #644 (upgrading this to a larger topic for all existing cores and new additions, not just PSX) and until we have button customization (#56) implemented…
Been thinking of a solve for buttons outside of the MFi controller default to make Start, Select (many systems) L3, R3 (PSX) and C buttons (N64) accessible on MFi controls like SteelSeries Nimbus or Gamevice which is what I am using.
#
What if we did something like this (names based on MFi and PSX layout button names), think of the L/R button combos as modifiers:
NOTE: This would be in addition to R Stick as C buttons and using □ and ▵ defaulted as most common used C buttons.
NOTE: above combo for Analog toggle button (PSX) is already implemented (notes in #826).
…The idea here is that controls are at least in a similar relation to their actual/original positions and relation to each other and the whole controller. Using all 4 shoulders mitigates accidentally triggering them (especially in fighting games).
The intent is to arrive at something fairly universal across the different systems. If we go with a custom mapping system (#56) then I would like to propose these as the defaults.
Perhaps, we can show something subtle on screen when the combo sets are pressed to inform users about the temporary virtual button mode they are in until they release the requisite combo sets (the L/R combos as modifiers).
#
[x] Toggles
not yet implemented in customize-able mapping layer, but hardcoded for now (notes in #826)
🚫 We DO NOT support unofficial builds installed from 3rd-party sites. (Official Install)
❓ Need help or have a suggestion? Join our Official Discord