Joystick mapping revamp?

https://github.com/MiSTer-devel/Main_MiSTer/wiki

Moderators: Mug UK, Zorro 2, spiny, Greenious, Sorgelig, Moderator Team

Locked
User avatar
Newsdee
Atari God
Atari God
Posts: 1561
Joined: Fri Sep 19, 2014 8:40 am

Joystick mapping revamp?

Post by Newsdee »

Hi Sorgelig,

I'm moving the github discussion here as it may be a better medium for it.

I've been mapping my various controllers across multiple cores, but I got tired of having to configure every single one. I wrote a python script to convert config between cores, but I have to say ending up with so many config files really bothers me.

I prefer the approach in MiST, which happens to be similar to RetroArch as well: have an internal virtual gamepad.

In essence it is an API for controllers where 1) physical controllers map their buttons to specific purposes (e.g. Start, A=Accept, B=Back), then 2) cores request mapping to that purpose API instead of polling random USB button IDs.

I noticed the virtual gamepad code of MiST was taken out, so I tried to avoid reimplementing it as is. What are your views on that feature?

The other alternative would be to use one specific core for configuring gamepads. I chose the SNES one but that is a bit arbitrary (it just happens that it has the most relevant button config across all cores). But we'd still need a way to translate from this mapping to other cores. The virtual gamepad solves that in a generic way.
Threepwood
Captain Atari
Captain Atari
Posts: 154
Joined: Thu Jan 10, 2019 10:06 am

Re: Joystick mapping revamp?

Post by Threepwood »

I never liked the way retroarch handles gamepad configs, because some cores (Nintendo) have A and B reversed and you have to setup per core remaps for the ones that do not match the default config. It gets especially annoying when you use an eight button arcade stick.

How MiSTer does it feels straightforward and reliable to me as you know the buttons are correctly mapped and you can backup the configs easily. Besides, don't the cores already assume a default when the controller "only" got mapped in the menu core?

I was about to suggest setting up a config repository where users can upload their configs from within the OSD and rate them. MiSTer could then download the "best" config on the fly once a controller is plugged in for the first time. But honestly, for what? To save a user pressing maybe 12 buttons twice and then it works perfectly?

I have about 13 different gamepads and sticks and I at least don't see how a change in controller handling would improve anything besides making it more hit and miss and thus more complicated.

Maybe move all the configs into one folder and prepend the core name to the filename so we can sort per core and only have to backup one folder? The amount of config files itself is not an issue to me.
User avatar
Newsdee
Atari God
Atari God
Posts: 1561
Joined: Fri Sep 19, 2014 8:40 am

Re: Joystick mapping revamp?

Post by Newsdee »

The default mapping is not enough for some cores since it only has 4 buttons and ignores purposes. That said, we could modify the firmware to accept more buttons in the fw mapping definition, and assign a purpose (e.g. Start, Select).

To use your example, it would make setting up an Arcade stick much easier with only one mapping. The central mapping is relevant to physical layout and you can choose how you want it (e.g. A B vs. B A). Then cores would pick it up by default without further mapping needed.

In oher words the core remap that you mention would be internalized. We'd still have a central repo of configs, but instead of being per core and per josytick, it would be per specific controller (by VID:PID).

There are some controllers that spoof VID:PID, but then they are careful to respect the original physical layout. E.g. 8bitdo M30 places "Nintendo A" in an appropiate location when using the Switch Pro mode.
Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Joystick mapping revamp?

Post by Sorgelig »

This is where user preference cannot be standardised. Even PlayStation has 2 different configs for Asia and rest of the World (i mean X/O meaning). So even this fact will divide users who like X as accept and who likes O as accept.
I'm not sure if i understand right about that MiST has predefined button functions for cores like start or select. It's not true. Core gets a raw 8 bits as 8 buttons without strict map for buttons higher than 4th.
This is exactly the same as on MiSTer.
There is some pseudo-standard where directions and up to 4 buttons are defined. It's up to the core to place the most important buttons in first 4 buttons. Basically cores requiring up to 4 buttons are ready to use from the beginning.
Not all cores have start and/or select buttons. So you can't just fix the positions for these buttons.

May be it's better to collect the system map of buttons for the gamepads (defined in Menu core) rather than collect it for every core? System map is more or less the same for all users. And it's probably a little confusing for newbies as it includes additional important steps. Sometimes due to special behavior of game controller it's hard to correctly pass the controller setup in Menu core - this is where predefined config file may help.
Wile defining the buttons inside the core is more straight forward and can be done by any user.
User avatar
Newsdee
Atari God
Atari God
Posts: 1561
Joined: Fri Sep 19, 2014 8:40 am

Re: Joystick mapping revamp?

Post by Newsdee »

Sorgelig wrote: I'm not sure if i understand right about that MiST has predefined button functions for cores like start or select. It's not true.
I am referring to this: https://github.com/mist-devel/mist-boar ... ickMapping
It is not strictly enforced, but many cores expect button 4 as start (for example).
Not all cores have start and/or select buttons. So you can't just fix the positions for these buttons.
Right, this isn't about fixing positions but have a way for a core to request buttons by function, at least by default. For example, it could pass in config string the buttons it expects and Main would map them to that order (e.g. B A Sel Start).

The current mechanism could still be preseved for user override if desired.

Also, I suspect user preferences will be finite (e.g. playstation XO vs OX) so that could be addressed by INI setting.
May be it's better to collect the system map of buttons for the gamepads (defined in Menu core) rather than collect it for every core? System map is more or less the same for all users. And it's probably a little confusing for newbies as it includes additional important steps.
Yes, I'd like to do that and add some more info e.g. whether an analog stick is present and a base physical layout info. If we follow SNES naming as standard (to take an example) we'd know the right most button is A, so can apply for a core as desired (e.g. for SMS button II is the most on the right).

Perhaps a first step would be to add some more buttons to the menu core?

e.g. naming them start, select, left trigger, right trigger.
Then, mouse emu could map to those buttons, and the Main setup would be a little more intuitive for users.
User avatar
Newsdee
Atari God
Atari God
Posts: 1561
Joined: Fri Sep 19, 2014 8:40 am

Re: Joystick mapping revamp?

Post by Newsdee »

Let me recap and collect some of the concerns raised on github as well.

Here is a refined proposal that reduces changes to the code as much as possible but still addresses what I'm after.
What do you think of this?

Goal/Problem to Solve
  • Provide a better default joystick mapping for cores
  • Reduce or eliminate the need to apply manual mapping
  • Allow users to contribute mapping for new physical controllers
Method
  • Keep the current mechanism as override
  • Define a standard mapping that cores can translate from by default
  • Make any mappings configurable by external files
  • Prevent major changes to the current UI or current code
Problems / Concerns
  • There is no central reference mapping that can be used
  • Users may have specific preferences on layout
  • Users may not like the original console layout
  • Original layouts can have variations (PS XO vs OX, or Neo Geo original vs. Neo Geo mini)
Proposals

1 - Use the menu core mapping as reference
Keep current button order (and function), but relabel mouse buttons to have more meaning:

Code: Select all

    joy_bcount = 13;
    strcpy(joy_bnames[0], "Btn 1 (OK/Enter/A)");
    strcpy(joy_bnames[1], "Btn 2 (ESC/Back/B)");
    strcpy(joy_bnames[2], "Btn 3 (Backspace/X)");
    strcpy(joy_bnames[3], "Btn 4 (Y)");
    strcpy(joy_bnames[4], "Mouse Move RIGHT");
    strcpy(joy_bnames[5], "Mouse Move LEFT");
    strcpy(joy_bnames[6], "Mouse Move DOWN");
    strcpy(joy_bnames[7], "Mouse Move UP");
    strcpy(joy_bnames[8], "Left Trigger / L");
    strcpy(joy_bnames[9], "Right Trigger / R");
    strcpy(joy_bnames[10], "Select/Middle Trigr");
    strcpy(joy_bnames[11], "Start/Mse. Emu/Snipe");
2 - Create a core config file
Which will translate from Core mapping to the one specified by core.
Can be maintained externally (no change of HDL files) but need to be in sync with HDL definition.

Code: Select all

name=NEOGEO
button_1 = A
button_2 = B
button_3 = X
button_4 = Y
button_5 = SELECT
button_6 = START

name=GENESIS
button_1 = A
button_2 = B
button_3 = R
button_4 = START
button_5 = SELECT
button_6 = Y
button_7 = X
button_8 = L
3 - Keep existing logic
If not core config is found, revert to current behavior.
User can override with their own mapping by using the built-in mapping UI.

4 - Add VID:PID alias look up table
This is merely cosmetic, but will help tell users there is a predefined mapping for their controller.
Will be done as an external file loaded at startup (so as to allow expansion and avoid hardcoding)

I will make the changes for this if there are no further concerns.
Last edited by Newsdee on Wed Sep 25, 2019 4:45 am, edited 1 time in total.
User avatar
Newsdee
Atari God
Atari God
Posts: 1561
Joined: Fri Sep 19, 2014 8:40 am

Re: Joystick mapping revamp?

Post by Newsdee »

Here is how it would look like when mapping the main menu core, if we change labels and the joypad is recognized.

Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Joystick mapping revamp?

Post by Sorgelig »

So, if someone will use Genesis gamepad with Genesis core then in gamepad settings he will be asked for buttons LT/RT where he has to press C/Z? And in the Core settings he will be asked again for LT/RT buttons where he has to press C/Z?
While neither gamepad nor core have these RT/LT originally...
Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Joystick mapping revamp?

Post by Sorgelig »

Newsdee wrote:2 - Create a core config file
There was a big milestone in MiSTer when i removed need of config files for joystick and allowed to do everything by simple button definition in OSD. Now you tell me scrap the idea and use config file again??

I still don't see how new way is easier than current one. You chase the one single idea: get the joystick ready out of the box, but don't see collateral issues and hassles.

It's much better to write a good guide explaining how to define joystick in the Menu core, why these dpad/analog tests are required. When it will be written in good English language, it won't be confusing or hard to understand.
Universality sometimes can be not an easier way, but well, it's universal!
User avatar
Newsdee
Atari God
Atari God
Posts: 1561
Joined: Fri Sep 19, 2014 8:40 am

Re: Joystick mapping revamp?

Post by Newsdee »

Sorgelig wrote: removed need of config files for joystick and allowed to do everything by simple button definition in OSD. Now you tell me scrap the idea and use config file again??
I am building upon it, not scrapping it.

At the moment, the default mapping does not work for any of the 16 bit cores.
There are not enough buttons defined in the main menu.
So I am making a default mapping that works more naturally with these cores.

My suggestion to use files is, specifically, in response to your concern (on github) that we need to modify each core. We can avoid per core config if we use a config string from the core, if that is more desirable. If a core had no config we would still revert to the current handling.

By using the menu joypad config as main mapping, we reduce the need to remap manually, if the user is happy with the default mapping.

If they are unhappy they can still remap. The difference is that, today, a user always need to remap for the 16 bit cores.
I still don't see how new way is easier than current one. You chase the one single idea: get the joystick ready out of the box, but don't see collateral issues and hassles.
What this is doing is add knowledge in the system about what kind of gamepad a core expects. e.g. the Genesis core can declare it has 6 face buttons, and if a gamepad is SNES-like, we have an automated translation by default.

If both gamepad and core have similar type (both Genesis) then a different mapping would be applied as default.

Users will be able to contribute config files (per controller) that feel natural for main relevant core but also work decently with other types of cores. They would be created with current menu.
Sorgelig wrote:So, if someone will use Genesis gamepad with Genesis core then in gamepad settings he will be asked for buttons LT/RT where he has to press C/Z? And in the Core settings he will be asked again for LT/RT buttons where he has to press C/Z?
There will be no change to today when remapping an override from OSD. User is free to assign any button to Left Trigger/Right Trigger.

The result of this change is that we can map multiple cores with only the menu core config. It greatly reduces the number of config files needed.
When it will be written in good English language, it won't be confusing or hard to understand.
Universality sometimes can be not an easier way, but well, it's universal!
I never said there was a problem with the mapping UI or the docs.

I am reducing the number of physical steps needed to setup a gamepad across many cores and improving upon the default mapping.

Which caveats am I still missing? And how is using less steps a hassle?
User avatar
Newsdee
Atari God
Atari God
Posts: 1561
Joined: Fri Sep 19, 2014 8:40 am

Re: Joystick mapping revamp?

Post by Newsdee »

Just to clarify (if it isn't obvious), I am no longer discussing the PR as it was previously,
but am looking at agreeing on a direction before I spend time making and refining other changes.
Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Joystick mapping revamp?

Post by Sorgelig »

So the whole hassle is just to avoid to enter the joystick setup in specific core once??
I don't see efficiency of the new code. It will be almost inexistent, especially if you don't agree the default mapping.
Current Input code is very complicated and easy to lost. I don't want to make it more complex without a good reason.
User avatar
Newsdee
Atari God
Atari God
Posts: 1561
Joined: Fri Sep 19, 2014 8:40 am

Re: Joystick mapping revamp?

Post by Newsdee »

Yes, it is a hassle.
It bothers me enough to want to code it and to bother bringing it up to merge.

I run more than 10 cores usually. When I get a new controller, I need to remap it at least 11 times right now.
And then per core, I often forget the original layout (especially if I don't have an original controller next to me, or internet connection; I travel often with my MiSTer) so control feels weird so I end up having to redo it.

I also have several controllers, so I end up mapping a lot.
If I want to share my mappings of my controller with somebody else, then I have to share 11 files for 10 cores.

That is all unnecessary complexity when we can control mapping from one central location with a bit of good logic.
You stated that we should avoid config files, and this goes into that direction. We also reuse the existing mapping UI (its unaffected).

You seem to assume nobody will like the new mappings, but I own several original controllers and can test we end up in a way that is natural to original machines. We can also make it work in ways that cater for different tastes if needed (e.g. swap buttons) by variants in INI (for example). We are not bound to a single logic and don't need to make it super complex either.

I have refactored the code to only call one function in input.cpp that delegates to another file,
so the change is now minimally invasive to the existing logic and won't break it in any way:

Code: Select all

int convert_from_menu_mapping(int dev) {
    if(!FileLoadConfig(get_map_name(dev, 1), &input[dev].map, sizeof(input[dev].map))) {
        return 0;
    }
    return map_joystick (user_io_get_core_name_ex(), input, dev); //from joymapping.h
}
I hear your concerns on not making the changes too complex, nor to break the mapping UI.
That said, relabeling the core mappings (as above) won't affect the logic but provide meaning to the users.

I am confident this will benefit many people or I would not bring it up.
I feel that perhaps you do not think it is a problem, but I hope my use case will make you see a different perspective.

I am open to suggestions in how I can make the code change safer both for coders and users.
Are you concerned this may surprise users? Perhaps we can disable it by default (ini settings) if so.
Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Joystick mapping revamp?

Post by Sorgelig »

Ok, leave it for some time. I will think about it and come back later after your suggestion and my thought will be settled down.
Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Joystick mapping revamp?

Post by Sorgelig »

After some thinking about virtual gamepad and how to fit it transparently to existing cores i have more clear picture now. Generally it will use the Newsdee's idea:
1) We use SNES gamepad as virtual gamepad.
2) In menu core following keys will be defined:
A,B,X,Y,Start,Select,LT,RT. Analogue tests and definitions (and mouse) will remain the same.
3) Main will try to load core specific map, and if failed, then will try to guess the default map according to buttons names supplied by core and fill the internal map structure. It should be done on core start once (not runtime translation). Analog X/Y definition must be mapped to alternative dpad control. INI won't be used.
4) User will be able to assign keys as it's already implemented - so it will cancel (3)

For button guessing, probably not much heuristic is required. So besides the original button names, Fire/Fire1/Fire 1 can be mapped to A, and Fire2/Fire 2 to B. Fore genesis there must be exception where C will be mapped to LT and Z to RT by default.

There will be some cores not able to use default map because non-standard button names - i think it's not a problem, these cores will be updated to use standard names. So, no need to make a hard guessing.

Newsdee, what do you think?
User avatar
bootsector
Atari User
Atari User
Posts: 33
Joined: Wed Aug 21, 2019 11:51 am

Re: Joystick mapping revamp?

Post by bootsector »

I really LOVE the idea of a Virtual Gamepad for MiSTer!

My two cents is that the Virtual Gamepad be something based on XInput than SNES pad, so this gets more future-proof.

Aside of additinal buttons being available for current and future cores, we get a home button too! 8)

Code: Select all

typedef struct {
	uint8_t rid;
	uint8_t rsize;
	uint8_t digital_buttons_1;
	uint8_t digital_buttons_2;
	uint8_t lt;
	uint8_t rt;
	int l_x;
	int l_y;
	int r_x;
	int r_y;
	uint8_t reserved_1[6];
} XInput_t;

// digital_buttons_1
#define XINPUT_DPAD_UP		0x01
#define XINPUT_DPAD_DOWN	0x02
#define XINPUT_DPAD_LEFT	0x04
#define XINPUT_DPAD_RIGHT	0x08
#define XINPUT_START		0x10
#define XINPUT_BACK		0x20
#define XINPUT_LEFT_STICK	0x40
#define XINPUT_RIGHT_STICK	0x80

// digital_buttons_2
#define XINPUT_LB		0x01
#define XINPUT_RB		0x02
#define XINPUT_HOME		0x04
#define XINPUT_A		0x10
#define XINPUT_B		0x20
#define XINPUT_X		0x40
#define XINPUT_Y		0x80
So the idea is to map from XInput as the Virtual Pad to everything else, including SNES.

What do you guys think?
Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Joystick mapping revamp?

Post by Sorgelig »

There is no advantage to stick to exactly xinput. New way doesn't exclude initial joystick setup in Menu core. Not all joysticks use xinpit mode. I would say - only few are using xinput. New way doesn't change internal structure of map. It's more like "side" helper on top of exiting code.
Also, there is no goal to cover ALL possible keys. It's just for basic keys listed above. This covers 99% of cores. And it's pretty much enough without plans to extend the basic buttons list. There is a manual button definition per core. So cores like ColecoVision with phone-style keyboard will still require explicit definition for extra buttons by user according to gamepad he has.
User avatar
Newsdee
Atari God
Atari God
Posts: 1561
Joined: Fri Sep 19, 2014 8:40 am

Re: Joystick mapping revamp?

Post by Newsdee »

Sorgelig wrote: For button guessing, probably not much heuristic is required. So besides the original button names, Fire/Fire1/Fire 1 can be mapped to A, and Fire2/Fire 2 to B. Fore genesis there must be exception where C will be mapped to LT and Z to RT by default.

There will be some cores not able to use default map because non-standard button names - i think it's not a problem, these cores will be updated to use standard names. So, no need to make a hard guessing.

Newsdee, what do you think?
Yes, this is basically it.
Just adding buttons to the main menu core would go a long way.

The only part that I think needs a bit of refinement is step 3 because the physical location is different between brands.
But this location is consistent in most cases:
  • Nintendo always had (B, A), from NES to Gamebody to SNES, etc, to even the Switch).
  • Sega has (A, B) from the SMS to Genesis to Saturn [putting aside the L and R]
  • SNK has (A, B) and other names (C D)
  • NEC/PCE is a bit more tricky for 6 buttons. Otherwise it's C, B, A
I know it may seem pedantic to try to match physical button location...

however, some games did display a gamepad on screen, or mapped functions that made sense for a direction
(e.g. using the 4 face buttons as a dpad).

So I think it would make sense to try to match the most commonly used controllers for that machine.
(I know users can always remap, but it would reduce the probability of needing to remap at all)

@bootsector
The current proposal already gets close to that standard since we have 2 analog sticks, one OSD button, and a mouse already in there.
I don't think we need the rest since it's unlikely we can do PS2 emulaiton (or newer) on the DE10. If that ever happens we can justrevisit it then.
Last edited by Newsdee on Thu Oct 10, 2019 2:14 pm, edited 1 time in total.
User avatar
Newsdee
Atari God
Atari God
Posts: 1561
Joined: Fri Sep 19, 2014 8:40 am

Re: Joystick mapping revamp?

Post by Newsdee »

Here is an illustration of what I mean by the physical location:
Image
Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Joystick mapping revamp?

Post by Sorgelig »

Newsdee wrote:The only part that I think needs a bit of refinement is step 3 because the physical location is different between brands.
But this location is consistent in most cases:

Nintendo always had (B, A), from NES to Gamebody to SNES, etc, to even the Switch).
Sega has (A, B) from the SMS to Genesis to Saturn [putting aside the L and R]
SNK has (A, B) and other names (C D)
NEC/PCE is a bit more tricky for 6 buttons. Otherwise it's C, B, A


I know it may seem pedantic to try to match physical button location...
I'm not quite sure what do you mean by this.
If you want to autodetect the gamepads to assign the buttons automatically in Menu, then i'm strongly against it!
I don't want to make a garbage can in vid/pid detection like it was before. I've put a lot of effort to make initial setup as much universal as possible. And it's quite good now. So i won't mess with vid/pid unless some specific gamepads absolutely require some tweak.
How C/Z buttons on Sega gamepad will be assigned by user in Menu core - it's up to the user. Same for other gamepads. Most gamepads today resemble either PS or XBox gamepads, so they have pretty much SNES layout.
User avatar
bootsector
Atari User
Atari User
Posts: 33
Joined: Wed Aug 21, 2019 11:51 am

Re: Joystick mapping revamp?

Post by bootsector »

Thanks, Newsdee! The physical location diagram will be a good reference when it's complete with other system's controllers mappings (NES, SMS, etc...).

Sorg, I think he means what's described in the diagram on how SNES buttons map to other joysticks, without any kind of detection (aside of the initial mapping-to-snes-buttons that will be required when setting up a new usb joystick).
User avatar
Newsdee
Atari God
Atari God
Posts: 1561
Joined: Fri Sep 19, 2014 8:40 am

Re: Joystick mapping revamp?

Post by Newsdee »

No, this is entirely agnostic to vid/pid. And I think it does work in keeping it universal.
Let me try to explain better.

When I talk about a SNES "Virtual Gamepad" I mean it in two literal ways:
The button naming convention on one hand, but also the physical location of those buttons as if it were a SNES controller.

It is up to the user to take their "real world" controller (of unknown shape to us or MiSTer main),
and define a mapping to a layout that is presented as standard, the "virtual" SNES controller.

How it works: we will document to users that they should imagine they are assigning buttons to where it would be on a SNES controller
(or better, a "MiSTer Gamepad" with an extra analogue strick and OSD button... resembling conveniently to a SNES button layout).

Then internally:
1) MiSTer asks and records initially the user input mapping into this standard (naming + layout).
2) Any translation needed to a core is done by going from "virtual SNES" -> "Core controller"
3) Many cores fall into similar "brand layouts" as described, so core could request one of the mappings

This is entirely universal since the complexity is dealt by user at step 1,
and "requested" by core authors at step 3 when they write the core (or added later).

If a core does not define any standard we just feed it the default mapping, no changes needed, same logic as today.
I hope it is clearer and it does go into the direction that you are going for.

We would need those docs and some graphs, and I'd be happy to write one once we're done with the technical changes.
User avatar
Newsdee
Atari God
Atari God
Posts: 1561
Joined: Fri Sep 19, 2014 8:40 am

Re: Joystick mapping revamp?

Post by Newsdee »

Also (but it's a separate item) the reason why I added VID/PID initially had a different intention.

It was to flag which controllers were known by MiSTer and we provided some kind of mapping as a file.
That is purely cosmetic. I think it would be more user friendly, and reassuring to new users.

In practice what it really means is there was a mapping predefined for that controller.
That can be done entirely by using the existing file (e.g. we add a field that main can read but has to be edited in).
[to clarify: technically that means we use the same mapping UI as today, but then edit the ini on a PC in Notepad, anyboy can do it]

But what it means is this: imagine a user has a Genesis mini and wants to use the gamepad with MiSTer.
They will plug it in and feel "hey, MiSTer already knows my controller", and most cores would work quite naturally.

The above only needs minor tweaks to the code, can be dealt with community contributions (e.g. save ini files),
So I think it's universal and flexible. If not, I still feel it could be refined to get there.
Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Joystick mapping revamp?

Post by Sorgelig »

I want to keep the gamepad as black box.
It's ok if someone will gather map files for different controllers with pre-defined settings. But it must be a secondary, not primary.
Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Joystick mapping revamp?

Post by Sorgelig »

Actually i don't ask for implementation..
I can do it myself when i will finish my current tasks..
I don't want it to be de-railed to something monstrous with bunch of configs.
Locked

Return to “MiSTer”