flipBX - Gaming buttons (non-)standardization on Pyra


Christoph.Krn

Christoph.Krn

Advanced Member
Joined
Mar 17, 2009
Messages
2,119
Location
Germany
I'd like to discuss something which I'm cautiously optimistic could mitigate some of the Pandora's button inconsistency problems on the Pyra (for more information, see the "Short problem summary" and "Proposed solution" sections at guihints - preview01, 02).

In essence, different software will use the gaming buttons in different ways, and this can be overly frustrating for users. As far as users' settled habits are concerned, there is no THE ONE RIGHT WAY™ of mapping the gaming buttons. Muscle memory is so strong that you can constantly trip over mappings which you aren't used to, which is why developers SHOULD use something like guihints to make software less unusable (see PNDManager, for example). Alas, the severity of the problem is easily underestimated by individual developers who know little about usability, and in addition, guihints may in some cases require image editing knowledge / graphic design experience that many individual developers do not have.

As far as user habits are concerned when it comes to pushing buttons to operate software, navigating menus in particular appears to be a big problem.

Luckily, to my knowledge (I might be wrong about this, please absolutely do correct me if I am), it just so happens that across the common video gaming systems with four gaming buttons in a diamond shape, and as far as menu navigation is concerned, the very most famous patterns of button mappings are these two:

  • What I call the "Kyoto" pattern: Right-hand gaming button is "Confirm", bottom gaming button is "Return".
  • What I call the "Tokyo Western" pattern: Like the Kyoto pattern, but the other way around.
...so, on the Pandora there are no commonly agreed upon button mapping standards (which, in and of itself, I actually consider to be mostly a GOOD THING™ outside of menu navigation, because different software often does require different button mappings). Several efforts of standardisation have (naturally) failed.
For the Pyra, instead of trying to strictly standardize, we could suggest the two above patterns as sort-of "defaults" for menu navigation in fullscreen software, and encourage all developers to deviate, but use guihints then. Why I'm cautiously optimistic that this could actually work? Combined, "Kyoto" and "Tokyo Western" cover a large share of people who play video games (as far as settled habits for menu navigation are concerned), but they happen to use the exact same physical buttons, and that's neat-o, because it makes it rather easy to create a system-wide setting with which any user can easily switch between the two most-used patterns for all supporting software. If a couple of widely-used(-ish) applications supported this setting, then it could see more use in newly created software. Currently, there even is the chance to put this into the Pyra's first-boot wizard, so that this user preference would be set on every Pyra from the get-go.

Traditionally, PNDManager has been using ( B) to confirm and (X) to return. If you haven't noticed yet, PNDManager has recently received functionality to allow for flipping the mappings of the ( B) and (X) gaming buttons, so that people can get an idea about flipBX. In PNDManager version 1.4.1.1, press the F9 key to open the settings, and one of them allows switching between "( B) Confirm\n(X) Return" and "( B) Return\n(X) Confirm". This setting is NOT system-wide (yet).

If you have anything to say about this idea, please go ahead. This thread here is also to suggest and discuss the technical implementation details of a potential system-wide flipBX. This thread is _NOT_ thought for discussion about standardization of other buttons (unless it's relevant to flipBX in some way). If you want to have such a conversation, please strongly consider opening a separate thread instead.
 
Last edited by a moderator:
PNDManager works as a kind of proving ground here. If you're more used to, as called by Christoph.Krn, "Tokyo Western" mapping, you can try using that in PNDManager and see if it makes a difference for you. If this is seen as a Good Thing, something like it can be implemented as a global setting.

I actually thought about how this could be implemented so that the software itself wouldn't need switching for different contextual mappings. It would be possible to make a doodad that listens to game button events and for some or all of them emits a second key event through its own evdev device. The mapping would be configurable within the doodad. There are several key codes we could repurpose for this, for example KEY_OK. This would be suboptimal for action button mapping as it will possibly have some miniscule lag, but I've successfully played Battletoads with a similar setup so it can't be too bad. Another upside is that this is a completely userland solution.
 
One way to implement this would be to decide on some environment variables to encode the desired behavior. I suggest one variable per "action", so it can be extended to more than just confirm and return.

By using environment variables it is rather easy to configure system-wide defaults and still have application-specific exceptions if needed.

The value of the environment variable would be the keycode. Say END ( B) is 115 and PAGEDOWN (X)  is 117, then you could have something like this:

export PYRA_ACTION_CONFIRM=115

export PYRA_ACTION_RETURN=117

(or the other way around)

These could go in some file in /etc/pyra/button_mappings, which could be included in bashrc or some other initialization/launch script.

We could start with those two, but of course many more actions could be defined, and it would be up to the application to know about and respect those environment variables. E.g. we could also have PYRA_ACTION_JUMP, PYRA_ACTION_MAIN_WEAPON, and so on.
 
I wonder how this would work in emulators.  Say you're emulating a Nintendo platform which uses the Kyoto mapping, but have Sega/Tokyo set as your BX preference, does it swap the buttons for you?  Does it also swap X and Y?

I guess it's down to the emulator author what it does, but it might be good to discuss what people want.  Personally I have slightly odd muscle memory in that I am used to Nintendo buttons from the Gameboy/N64, but my first four button system with letters was the Dreamcast, so if a Nintendo game asks me to press Y I always head for top before having to correct myself.  If X and Y were swapped also it would probably aid me in the short term, although reinforce my mental mapping of Y to top in the longer term.

But perhaps we need an extra orthagonal setting; whether to leave emulated buttons as is on four button systems.  Or perhaps there are actually not that many four button systems in the scheme of things, so that's best put in the preferences of those specific emulators?

Also, I wonder what the bootloader will use?  The Pandora bootloader uses Nintendo/Kyoto mapping IIRC.  Does a bootloader actually need a 'cancel' button even?
 
I was under the impression that gaming systems had a primary and secondary button. The reason why this is changed on ABXY and BXAY is because it isnt at all clear which one is 1 and 2, but its clear that they are different from 3 and 4.

A is primary, and in the location most available to your thumb. I think thats the way to play, because its ergonomically better. Granted doing this differently only benefits the ones that have to stay compatible with their own library.

On playstation its different between what region it is.

Which is why those symbols dont even make sense half the time. For fighting-games, its always orientation, and since its not only the NEO-GEO anymore, across multiple systems, direction is what holds true.

Additionally, with GUi-hints, i find myself typing x on the keyboard, even if its a round button x im told to push.  Going with something that isnt a likely keyboard equivalent solves this.

←↑↓→ and <^v> works even without the button-connotation. 

Similarly, if you want a pattern and half of them are patented, and the sega-layout activly confusing. Going with directional visuals solves it, and is better.

XBAY is the absolute worst idea on every level. Staying compatible with confusion is not good.
 
Last edited by a moderator:
I was under the impression that gaming systems had a primary and secondary button. The reason why this is changed on ABXY and BXAY is because it isnt at all clear which one is 1 and 2, but its clear that they are different from 3 and 4.
Click to expand...

That is the reason, why I love the Gamecube controller. The mapping is so obvious:

  • A is the main action button
  • B is some secondary button
  • X and Y are similar third buttons
It is not only the position, but also the color of the buttons. It's just perfect.
GameCube_controller.png
 
Last edited by a moderator:
I propose some central place to store pyra-specific user-specific configuration variables. As per Freedesktop specification, a natural place would be at $XDG_CONFIG_HOME/pyra with configuration files for various categories. In the case of flipBX, the file would probably end up being .config/pyra/input or such. This configuration would not be a place for application-specific stuff, though some configuration options may at first be only used by individual applications. The point would be those options are something that other applications may want to take into consideration as well.

If such system is agreed upon, I further propose a wiki page for listing potential and in-use variables.

The system may very well not end up being used that much, but there's little downsides to having it even for the rare cases.
 
Christoph.Krn said:
I'd like to discuss something which I'm cautiously optimistic could mitigate some of the Pandora's button inconsistency problems on the Pyra (for more information, see the "Short problem summary" and "Proposed solution" sections at guihints - preview01, 02).

In essence, different software will use the gaming buttons in different ways, and this can be overly frustrating for users. As far as users' settled habits are concerned, there is no THE ONE RIGHT WAY™ of mapping the gaming buttons. Muscle memory is so strong that you can constantly trip over mappings which you aren't used to, which is why developers SHOULD use something like guihints to make software less unusable (see PNDManager, for example). Alas, the severity of the problem is easily underestimated by individual developers who know little about usability, and in addition, guihints may in some cases require image editing knowledge / graphic design experience that many individual developers do not have.

As far as user habits are concerned when it comes to pushing buttons to operate software, navigating menus in particular appears to be a big problem.

Luckily, to my knowledge (I might be wrong about this, please absolutely do correct me if I am), it just so happens that across the common video gaming systems with four gaming buttons in a diamond shape, and as far as menu navigation is concerned, the very most famous patterns of button mappings are these two:

  • What I call the "Kyoto" pattern: Right-hand gaming button is "Confirm", bottom gaming button is "Return".
  • What I call the "Tokyo Western" pattern: Like the Kyoto pattern, but the other way around.
...so, on the Pandora there are no commonly agreed upon button mapping standards (which, in and of itself, I actually consider to be mostly a GOOD THING™ outside of menu navigation, because different software often does require different button mappings). Several efforts of standardisation have (naturally) failed.

For the Pyra, instead of trying to strictly standardize, we could suggest the two above patterns as sort-of "defaults" for menu navigation in fullscreen software, and encourage all developers to deviate, but use guihints then. Why I'm cautiously optimistic that this could actually work? Combined, "Kyoto" and "Tokyo Western" cover a large share of people who play video games (as far as settled habits for menu navigation are concerned), but they happen to use the exact same physical buttons, and that's neat-o, because it makes it rather easy to create a system-wide setting with which any user can easily switch between the two most-used patterns for all supporting software. If a couple of widely-used(-ish) applications supported this setting, then it could see more use in newly created software. Currently, there even is the chance to put this into the Pyra's first-boot wizard, so that this user preference would be set on every Pyra from the get-go.

Traditionally, PNDManager has been using ( B) to confirm and (X) to return. If you haven't noticed yet, PNDManager has recently received functionality to allow for flipping the mappings of the ( B) and (X) gaming buttons, so that people can get an idea about flipBX. In PNDManager version 1.4.1.1, press the F9 key to open the settings, and one of them allows switching between "( B) Confirm\n(X) Return" and "( B) Return\n(X) Confirm". This setting is NOT system-wide (yet).

If you have anything to say about this idea, please go ahead. This thread here is also to suggest and discuss the technical implementation details of a potential system-wide flipBX. This thread is _NOT_ thought for discussion about standardization of other buttons (unless it's relevant to flipBX in some way). If you want to have such a conversation, please strongly consider opening a separate thread instead.
Click to expand...

Yeah it's a good idea. I'm always using A as "confirm" and B as "return" as Tokyo Western patern:
  Y
X B
  A
 
Last edited by a moderator:
I'm a big fan of games that have a small button legend at the bottom of the screen, like in Skeezix's BattleJewels. Works great for menus and other static screens, like when the game is paused.
 
Bringing to the attention of the user that you should press a button, in the form of ABXY is broken, thus, the behavior of inhibiting it, is broken.

It serves, at best, no other purpose than try, in vain, to teach the user a competing paradigm.

For a gaming system that utilizes the gaming-catalogue of multiple, incompatible systems, it is a default loss.

What button is primary > or v depends on what the most comfortable position on the controller is. That button is A

And then someone came along and made B < ....
 
It may not be clear enough that flipBX is only for menus in software. Maybe it should be renamed to something else to make this clear ("MenuControl"?).

One way to implement this would be to decide on some environment variables to encode the desired behavior. I suggest one variable per "action", so it can be extended to more than just confirm and return.

[...]

We could start with those two, but of course many more actions could be defined, and it would be up to the application to know about and respect those environment variables. E.g. we could also have PYRA_ACTION_JUMP, PYRA_ACTION_MAIN_WEAPON, and so on.
Click to expand...

Okay, so let me explain this.

These comparatively extensive solutions have one thing in common, they require developers to actually make use of them, and this has been a problem before. Your specific suggestion, for example, may seem to be pretty straightforward at first, but the fact that the number of physical (gaming) buttons is fixed will make things difficult. When you remap one funtion as a user, then you often will also have to remap another. Then you will have to create a custom mapping for (almost) every piece of software, and eventually mappings can yet again end up easily differing between your applications for various reasons. These things aren't exactly beneficial towards a wide adoption.

I know that you are one of the people here who understand that there are problems with the button whatnots, but many developers give it a very low priority. That's why flipBX is reduced to the very core of the button problems. With a good benefit / implementation costs ratio, and a low amount of complexity for any user thanks to a set-and-forget nature, hopefully flipBX can become a (optional! everyone else can use guihints to achieve a similar level of usability) baseline that most people can agree upon. Potential other improvements could then be built upon it.

(Yes, yes, I know about FunKeyMonkey.)

I'm a big fan of games that have a small button legend at the bottom of the screen, like in Skeezix's BattleJewels.
Click to expand...

See guihints. Mislead understanding of how a software is to be operated (user's mental model) is a stealth issue though, who would file a bug report for it? So in the future, when you use a Pandora/Pyra software that's not a port or so, it's frustrating to use, and you think that it would be less bad if it had something like guihints, then file a feature request.
 

Bringing to the attention of the user that you should press a button, in the form of ABXY is broken, thus, the behavior of inhibiting it, is broken.

[...]

What button is primary > or v depends on what the most comfortable position on the controller is. That button is A
Click to expand...
Which button is the "most comfortable" depends largely on the individual on most controllers, based on factors such as muscle memory, hand size, and resting method.

flipBX is about muscle memory, the button labels don't matter in it. I would like to ask you to strongly consider not to introduce a discussion about button labels here, so that the discussion about flipBX can stay on track.
 
I propose some central place to store pyra-specific user-specific configuration variables. As per Freedesktop specification, a natural place would be at $XDG_CONFIG_HOME/pyra with configuration files for various categories. In the case of flipBX, the file would probably end up being .config/pyra/input or such. This configuration would not be a place for application-specific stuff, though some configuration options may at first be only used by individual applications. The point would be those options are something that other applications may want to take into consideration as well.
Click to expand...

Sounds fine to me.
 
Last edited by a moderator:
It depends entirely on how the designers of the control go about their business. Primary , the A being easiest to reach and/or rest on is always the case.

It is that way in software too, and given any controller, there is something to be said for just letting A be A. The ideal is however A on A without any change.

Something you cant have across the board if you do many systems, but it sure gets needlessly bad when you put secondary in 3/4 position.

And if you just want to have your legacy favourite, you cant without disturbing pageUp/PageDn or Home/End pairs, since they are printed.

That also breaks the notion of pairs, which are always 'A and B' and 'X and Y'. Notice how its not ABCD.

The problem is a multi-relational one, if you follow along, you get at best something native, but never without being inherently actively confusing on others.

Doing <^v> relates to all equally. :)
 
Last edited by a moderator:
Since it will not make these buttons accept or cancel in the DE or any productivity app, there is IMO very little to be gained (except perhaps for users only interested in gaming, depending on the level of adoption). OTOH there is nothing to be lost, so I'm in favor.
 
So, in a nutshell, the aim is to have a Global Env Variable set to control if primary button is B or X (and secondary X or B)?
 
So, in a nutshell, the aim is to have a Global Env Variable set to control if primary button is B or X (and secondary X or B)?
Click to expand...

Or, as I proposed, put this stuff in a configuration file under XDG_CONFIG_HOME? I suspect there will be other such small preferences that would be nice to have someplace.
 
B-ZaR said:
So, in a nutshell, the aim is to have a Global Env Variable set to control if primary button is B or X (and secondary X or B)?
Click to expand...

Or, as I proposed, put this stuff in a configuration file under XDG_CONFIG_HOME? I suspect there will be other such small preferences that would be nice to have someplace.
Click to expand...
Ok, this is fine for me too.
 
The only thing I'm unclear on here is what emulator authors should do.  I'd guess that most SNES players would want the original SNES layout, regardless of which button they set as their primary, but on systems where the buttons don't map so nicely to a diamond (with two extra buttons) should these settings have any influence?

I can imagine maybe NES players might want their primary as the I button and their secondary as the II button, and not be forced to use B and X, but I can't easily imagine how these settings would apply to N64 joystick layouts (leaving space for the camera control diamond), or even Genesis/Megadrive/Jaguar (three primary buttons).

But I guess we're in the same position as we were in the Pandora if you ignore those settings, and that's what most emulator authors will do.  And that's fine by me.

Edit: Also, won't XDG_CONFIG_HOME be ~/.config by default?  It might be appreciated by some if config settings could be stored on SD cards by default.  I guess I could always set XDG_CONFIG_HOME in my .bashrc (or one of the other boot/logon files) but it would be quite smart if it could do this automatically, perhaps with the automounter setting XDG_CONFIG_HOME when it mounts cards.
 
Last edited by a moderator:
You must log in or register to reply here.

Similar threads

Christoph.Krn
PNDManager users, what's your "Menu navigation" setting?
Replies
7
Views
931
rygD
rygD
P
  • Poll
Four Shoulder Buttons?
2
Replies
24
Views
4K
Pritchy
P
segaprophet
6 face buttons necessary?
2 3 4
Replies
72
Views
11K
Xaeo
Xaeo
Christoph.Krn
Parentheses format for button labels
2 3
Replies
50
Views
7K
rygD
rygD
_wb_
Mouse buttons on shoulders without losing shoulder modifiers
2
Replies
26
Views
8K
elw3
elw3
Back
Top