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

Multitap extensions to the controller interface #6

Open
andres-asm opened this issue Sep 7, 2014 · 1 comment
Open

Multitap extensions to the controller interface #6

andres-asm opened this issue Sep 7, 2014 · 1 comment

Comments

@andres-asm
Copy link

On many classic systems there was the option to have a multitap hooked up to a port. Now that option is irrelevant but since it fits with the retrospirit I was thinking the could be an addition to the retro_controller_description struct that can be used for such a goal.

struct retro_controller_description
{
   /* Human-readable description of the controller. Even if using a generic 
    * input device type, this can be set to the particular device type the 
    * core uses. */
   const char *desc;

   /* Device type passed to retro_set_controller_port_device(). If the device 
    * type is a sub-class of a generic input device type, use the 
    * RETRO_DEVICE_SUBCLASS macro to create an ID.
    *
    * E.g. RETRO_DEVICE_SUBCLASS(RETRO_DEVICE_JOYPAD, 1). */
   unsigned id;

   /* Multitap device attached flag */
   bool multitap;
};

That multitap flag could be renamed to something more generic, but by doing this we could have a mutitap attached setting in the frontend and still use different controllers for actual input.

@andres-asm
Copy link
Author

I've been checking cores, genplusgx for instance implements multitap on a per-port basis, but it's horrible since you have to add a controller for each combination:

#define RETRO_DEVICE_MDPAD_3B_WAYPLAY RETRO_DEVICE_SUBCLASS(RETRO_DEVICE_JOYPAD, 3)
#define RETRO_DEVICE_MDPAD_6B_WAYPLAY RETRO_DEVICE_SUBCLASS(RETRO_DEVICE_JOYPAD, 4)
#define RETRO_DEVICE_MDPAD_3B_TEAMPLAYER RETRO_DEVICE_SUBCLASS(RETRO_DEVICE_JOYPAD, 5)
#define RETRO_DEVICE_MDPAD_6B_TEAMPLAYER RETRO_DEVICE_SUBCLASS(RETRO_DEVICE_JOYPAD, 6)
#define RETRO_DEVICE_MSPAD_2B_MASTERTAP RETRO_DEVICE_SUBCLASS(RETRO_DEVICE_JOYPAD, 7)

This is quite horrid imho.
When I asked ekeeke about moving this to core options he agreed but he said he was told it should be done like this: ekeeke/Genesis-Plus-GX#33

Other cores have this implemented as core options which seems cleaner but a bit out of place:

var.key = "beetle_psx_enable_multitap_port1";
if (environ_cb(RETRO_ENVIRONMENT_GET_VARIABLE, &var) && var.value)
{
   if (strcmp(var.value, "enabled") == 0)
   setting_psx_multitap_port_1 = true;
   else if (strcmp(var.value, "disabled") == 0)
   setting_psx_multitap_port_1 = false;
}
var.key = "beetle_psx_enable_multitap_port2";
if (environ_cb(RETRO_ENVIRONMENT_GET_VARIABLE, &var) && var.value)
{
   if (strcmp(var.value, "enabled") == 0)
   setting_psx_multitap_port_2 = true;
   else if (strcmp(var.value, "disabled") == 0)
   setting_psx_multitap_port_2 = false;
}

A flag and a corresponding toggle under input options would be neater and would help with standarization.

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

No branches or pull requests

1 participant