Show gamepad in OSD when doing button mapping #127
Conversation
|
i don't see the need of such "picture" because of:
|
|
It helps understand the mapping process, especially when the user physical
gamepad is not "snes" shaped.
I added this after user feedback from various people that found the "magic"
confusing (on Discord). This was seen aa a solution that was easy to
understand without docs.
…On Wed, 23 Oct 2019, 10:37 AM sorgelig, ***@***.***> wrote:
i don't see the need of such "picture" because of:
1. Virtual layout is quite simple, so anyone understand it.
2. There is no hard mapping of buttons. For example A/B X/Y can be
swapped on specific gamepad which will confuse the user. Some gamepads have
quite different layout which from other side doesn't break the
functionality. User may have his own vision where each button should be
located on his gamepad.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#127?email_source=notifications&email_token=AC2S2ALJVINBCPR33O456CDQP62INA5CNFSM4JD2UF62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB72YBY#issuecomment-545238023>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC2S2AIQV2ILXNDABISQVCTQP62INANCNFSM4JD2UF6Q>
.
|
|
The letters are not important and are in fact misleading. A on xbox is different than A on snes is different than A on genesis. What is important is that the user understands the physical location of where the button is being mapped to, and that why the picture is important. The idea is to create mappings based on the physical layout of a pad, consistently. The actual labels are arbitrary. |
|
I still don't get it. When you enter this dialog you already have the gamepad in hands and see these labels on it. And just follow the letters you see on your gamepad, not this picture which may not represent your actual gamepad. I even don't say half of buttons/sticks are not shown on this pic. It more looks like a big icon from Windows or other GUI. But OSD doesn't use pictograms for other dialogs. So this looks like foreign design. |
|
I think the point is to help the users see what the original controllers looked like and bind them like so as close as possible. |
|
The point is to document that we conceptually map to a SNES physical layout as an agreed standard for MiSTer. In other words, it isn't the physical user gamepad but what is, conceptually, inside MiSTer. It basically adds a layer of indirection between the user physical controller and what the MiSTer uses.
We are not trying to represent every possible controller but rather "if it was for SNES, how would you map it"? and the default mapping drives from that. This physical layout without labels is why I started calling face buttons with compass directions. "North button" is consistent acros many gamepads regardless of what it is labeled. Yes, there are edge cases, but this seems to capture most of the needs and users seem to find it more intuitive to use. |
|
The gamepad in your hands has some random labels. For example, south-most button: Xbox will be A, Switch pad will be B, Playstation will be X. How do you ask the user to press the south most button? If you give them a picture that shows where "A" is, and then tell them to press "A" they can understand what you want them to press. If you just say "A" and they have an xbox controller, they will press the wrong button, and then NES will have buttons mapped backwards. Do you understand? |
|
OSD asks to press the button labeled "A" not the button located on south! So depending on your gamepad or your wish you can press either button labeled (on your physical gamepad) "A" or button you wish to be used as "A". |
But X on Playstation is not a letter but sign. It's still A or B depending on region. But anyway it just confirms the picture is wrong by many means. |
|
Mapping physical location is part of the intended concept. It makes it much more intuitive than trying to figure out where "your physical A" should be for it to work nicely by default for most cores. Remember that the purpose overall is to reduce config files and overrides. Using this picture makes it more obvious for users to get it right. The picture is "right" in that it represents the MiSTer internals as an abstraction. What user inputs by mapping is saying "these are the buttons I want for face buttons", "these are the buttons for shoulder buttons", etc. |
|
Also please note that we flash the active button to make it more obvious where it is. So even if the user ignores labels, they can quickly map their gamepads just by following visual cues. |
This contradicts the exact reason of having a virtual snes pad. Might as well name the buttons 1,2,3,4 to avoid confusion, its' the position that's important. |
no, it doesn't contradicts. Virtual gamepad is for defining set of common buttons. Where physically these buttons will be is up to the user. If someone is get used to have A button on south, then he can assign it there and get the Main Fire/Confirm on the south in all cores. If someone wants to get it on east, then he can define it there. It doesn't break the concept. It makes it more universal and adoptable. |
There is no point to having virtual gamepad then,, since the core goes by physical position. |
|
The user is still free to map to their preference. But the purpose of having an internal MiSTer gamepad is also to imply some positioning. If we have that, then defaulting can be made more accurate by default, which is the whole point for me. It makes documenting further mapping predictable. It is easier to say and use "this button is East like SNES A" than "I use A for East and hope it is, possibly, in SNES layout". |
it's up to you. You can treat it as no point. So this concept is not for you then. And the point is to have the list (not the really fixed to places) of buttons, so you won't have to define them in every core. |
Exactly the opposite. It's not only having the button already defined, but also with the original console position. |
|
That's not true at all. When you play snes or nes games, the layout of the buttons matters tremendously. The point here is to abstract the mapping into a standard layout so that the correct physical layout can be inferred from that mapping. That's why it's done by position, not by letter or anything else. Strictly physical position. Then you can start TG16, and I and II will be the right way, or gameboy, and A and B will the be the right way, etc. |
|
Genesis 3 button and 6 button can be mapped intuitively from SNES layout. As examples: SNES had 6 face button gamepads which had L and R on the right, and M30 has a SNES equivalency where it gives Z as L and C as R. Sure you can't map to both 3 button and 6 button at the same time, but it remains an intuitive default that can be easily explained. |
|
No, it's not how this feature will work. |
|
I am confused as to why do you consider the physical layout as not achievable? That is the point of having a standard. |
Please read the code. You will see the mapping is done by button names, not by physical positions. And this is the only logical way to map it automatically. You can't know where button A is physically located on original controller. And it even will be more confusing when you ask for A button in Menu core, and then in some specific core you will find the A button is in other place. Game asks you to press "A". You press A but nothing happens.. And only after angry complain in forums and FB you get reply "oh, this system has button A in place of button X". WTF? |
sure, and ABXY from Genesis are mapped exactly to ABXY of virtual gamepad. And it's different from original Genesis as A/B and X/Y should be swapped to be matched. This is what i'm talking about. I happy with label matching. If i will find it inconvenient i can always re-map it. But i want to have A button in all cores in the same place, not moving around. Same as Fire 1 i like to be on A and Fire 2 on B. Not like Fire 1 on Y and Fire 2 on A which could be more correct from positional point of view. |
|
I see your point, but what we are after is different, it's to make A move where it should be per core, and match the common controllers of that system. We could make the behavior change by user INI settings, so user can specify their own preference? |
|
Physical position is just suggestion, not requirement. If you use M30/Genesis gamepad, then most likely you will use Z for L and C for R, and most likely you won't like to change ABXY to other positions than they are labeled on M30. Otherwise you will always fight yourself to press A labeled as B and B labeled as A and same for X/Y.. |
|
Also: we can solve the intuitiveness of mapping by adding a controller test screen. Then user knows what is actually happening. You can send user complaints to me if that is the concern :) |
|
Please read my messages above. There is no way to know where physically buttons are located on original gamepad. |
|
Can new way through virtual gamepad provide ready to play environment for newbie users? - YES The main reason for new gamepad definition is to provide the button definition for all cores as a ready to use solution, so newbies will stop to complain "Ahh, my gamepad doesn't work in XXX core." |
Yes there is: this is exactly why we ask users to map to a SNES layout . They declare what (in their opinion/preference) matches that physical layout. Can labels only be ready to play? No, because it will result in unintuive button placement for many cases as console games expect their original controllers are being used. The new gamepad definition aims to reduce the need for specific mappings. |
I play games with layout i define and have no problems. So you are wrong.
It's only valid for SNES core. Cores provide labels without physical location. |
Not correct. New definition aims to provide SOME button definitions so any core can be controlled by gamepad. |
So technically new way has no any relation to physical map. It's all about labels map. As a developers you should understand from the code what all this is about. I don't understand why you switched off the logic and pretend to be a newbie with wish "I want a magic" |
|
You can make menu maps like B,A,,,Select,Start for NES, with spacers to tell it how to line up with the default mapping. |
|
It will require to modify all cores. Unmodified cores will get strange default layout. Probably it will be implemented sometime later. Currently you solve one problem but produce others difficulties. |
|
I understand we have a difference of opinion here. I assumed it was a bit clearer. If I undersrand you correctly, you are coming from the perspective of keeping button names the same regardless of where they are physically. So if e.g. the screen says "Press A" for Neogeo then user looks down and finds A, and done. If a controller has a different name (e g. playstation) they decide which label matches A (say Triangle). I would say this kind of mapping is best for a user with no direct experience of retro systems. It sacrifices physical accuracy for intuitiveness in finding buttons. There is another kind of user, which has more retro experience . They are aware of different gamepads configurations, and just wants an authentic experience without worrying too much about setup. This is especially relevant if you have experienced playing the original system with original controllers. Would you accept making this optional? We can cater for both styles depending on user preference. We need a good option for the ini e.g. : gamepad_layout=0 - map by label We can always have option 0 by default for a core, so your original intent remains in place, until a core author decides to allow support for mode 1. But then it is only used if the end user declares thenselves to want that behavior. Hopefully that will avoid surprises so even FB users that aren't very technical can use it nicely. If we have that option we greatly eliminate the need to map per core. I expect most intermediate users would want a "natural physical layout" for a core. But I also understand we want to cater to newbie users with less experience, and an option flag allows it too. |
|
I should add that I am fine relabeling face buttons "North, South, etc" instead of SNES names if that makes it more intuitive. We can do both e.g. "A (East)". |
|
MiSTer provides an option to define the buttons per core. No technical knowledge is required for that. Experienced retro users definitely can understand how to press menu button and enter the button definition. Current SNES layout already fits most cores to their physical buttons (if it possible). So we are basically talking about couple cores where buttons may be shuffled from their original physical position. So it's just a matter of re-defining the gamepad in these couple cores. It's much easier than mess with ini settings and make input subsystem more complex. Positional definition will require a lot of rewrite. Currently buttons are laid sequentially in config as they defined in the core. It's easy to handle for example when user want to re-define the buttons. Positional system with skips will require more handling and constant re-arrange. Many buttons have no positions as they are simply not defined (like power pad for NES or ColecoVision phone pad). |
|
Adding more buttons as we just did is a huge step, yes. But when I talked about SNES layout I always had the physical placement in mind as well. It isn't just about remapping a couple of cores, but each core per controller. As a developer it seems completely inefficient to have to remap when I know a few options can drive all/most cores nicely from one mapping. I am undestanding that your concerns are about users being surprised and complaining, and also about adding complexity to the framework. But this code can live encapsulated (it already is to some extent) so it should not affect other parts of the stack, unless I'm missing something? Can we cater for that in a way that we can preserve this feature? I can accept that you tell me advanced mapping may confuse completely new (non retro) users. But there is also a large community of retro users as well that would want that kind of behavior. To me, relying on a physical layout gives image/visual feedback which is understood by muscle memory rather than the brain (reading). I think between us we represent different point of views of various users. So hopefully we can provide a wide range of options. I can commit to document this all very nicely and make it as obvious as possible with screenshots, videos, etc. If that helps? |
|
While preferences for each people can be different, there is a basic common sense.. If you will tell to user that button A will be on B and B will be on X, X will be on Z and Z will be on A, then he will tell "What??". And this is per core shuffling. Sure some one would like it, but it's NOT common sense. While different system had different layouts, user will have to operate by a single gamepad in most cases. It will be a pain to remember where is specific button on each system while sticking to labels will make it common. |
|
@Newsdee basically all your talk about "what if i'm lazy to define the keys for core". And you are talking about this like you cannot define the layout. |
|
Please note, we do not need a rewrite for positional config. I can drive it from the current joy_map function with some extra flags, assuming user followed mapping using the SNES layout presented in UI. Cores could optionally request new mapping with a secondary joy string that is used only for defsult malling eg: Core labels (for override mapping): Default map labels (to match MiSTer internals): The existing code works same as today, but accepts an additional joy_balias that a core could define. I think that would be minimally invasive from current code and get what we are after at low risk. |
|
i will think about it |
|
I understand your intention. What I am asking is to extend it slightly, so as to cater for advanced users who have a predictable want (match physical layout). It is not even really advanced users, but owners of retro hardware vs. people who only used PCs. If your concern is the work needed fo refactor the code, I think we can avoid that with how I suggested above. |
|
ok. i will define additional option for cores used for physical mapping in case some INI option is enabled. |
|
Sorg, I am in your side and trying to work with you here, offering to shoulder user feedback and avoid, as much as I can, this being more work for you. I take your concerns seriously and want to cater for them. I am sorry if my trying to understand things fully and present my perspective came across in the wrong way. As you know, I've been around for a while and am finally starting to contribute more to what I can. PM me (forums or FB) or let me know if you prefer that we discuss things in any other way. I'd be also glad to chat about other ideas in return. My doors are open. |
|
I think adding this drawing of the Virtual Pad helps a lot for the joypad first mapping. I'd like to add my two cents for the overall solution though: 1 - Put a drawing of the MiSTer Virtual Pad in the Wiki with buttons on it |
|
btw, i don't see any flashing while defining the keys in Menu core |
|
ok. i see where is the problem |
Add visual representation of the internal MiSTer gamepad when mapping from the menu core.
(it is not shown when mapping from regular cores)
This will help users map their controllers more intuitively.
The text was updated successfully, but these errors were encountered: