Standardized Controls

[foxblock]

You remember back in the day on every Nintendo system you always knew which buttons to press to go through menus - it always was A to confirm/proceed and B to cancel/go back. In case this de-facto standard was not followed confusion at the player's end could be guaranteed.


This even worked across generations of consoles as those two buttons stayed the same (location, naming, even colour in some cases).


For the Playstation it's basically the same.


Now sadly the UI situation on the Pandora is a mess with some not even fitting on the screen, some programs using the action buttons (ABXY), some using Space, Enter or Escape, etc.


There has been some talk about a "standard" for how programs should behave on the Pandora or how interfaces should look and while I think that's an important topic, I actually don't want to focus on that here.


I want to start with something simpler, something easier to integrate, yet with a few benefits.


As described above I would like to develop a standard for interface controls (mostly aimed at games or programs with game-like interfaces - think minimenu, PNDStore or Panorama), including which button should select an item in a menu, which button(-combination) should exit a program, etc.


Benefit of this would be a standard for programmers to implement without having to think about it, new users could be referred to it, in short: less confusion, more consistency.


In general one could just go with the way minimenu does it I think, but there is no _written_ standard so I would like to discuss it here before anything goes up on the wiki.


I am pretty sure there already has been a discussion about this before, but it has been quite some time ago and I was not able to find any recent threads or wiki articles about the matter - please give me links if I am incorrect.


Here is the proposed control schema. (read for the reasoning behind it)


B - Accept menu choice, confirm (in pop-up dialogues, etc.)


X - Go back in a layered menu, cancel (in pop-up dialogues, etc.)


Start - Pause (in games), bring up menu (with functions including quit, go back to menu, resume, restart, options, etc.)


Fn+Q (ESC) - Exit program (with or without prompt)


The application should provide the option to quit (through Fn+Q) at any time. Furthermore the pause menu (by pressing Start) should be available where appropriate and supply a "Quit" (to desktop) or "Go to menu" option with the main menu in turn offering a "Quit" option.


Space - Overlay menu in emulators


Pandora key - this button should not be handled by the application at all and solely left to the OS

Spoiler

Old schemata, use for discussion purposes.


The minimenu way (already implemented de-facto standard due to use in minimenu and other applications)


B - Accept menu choice, confirm (in pop-up dialogues, etc.)


X - Go back in a layered menu, cancel (in pop-up dialogues, etc.)


START - Pause (in games), bring up menu


SELECT - Exit program, go to menu (in games)


The Nintendo way (well known standard from home consoles, sadly kinda awkward due to the location of A/B buttons)


A - Accept menu choice, confirm


B - Go back in a layered menu, cancel


START - Pause


SELECT - Exit program


The PC way (using ESC as a well known button on the PC, slightly hidden on the Pandora due to use of Fn key - used in Panorama for example)


B - Accept menu choice


A - Go back in layered menu, cancel (opposite position of B )


START - Pause


FN+Q [ESC] - Exit program


Some programs use 'Q' to exit, then there also is the Pandora button, but I don't know if that can be used in applications without problems.


I only included basic functionality (which is needed in almost any application) here, one could also expand the list to some slightly more obscure (read: not necessarily needed in every application, yet not specific to only one) functions.

Discuss.

 

[fusion_power]

I really wish, we already had such standards, it already was dicussed Years ago and I always was for basic standards in Pandora controls. But sadly, Standards seems to be the pure Evil in the Homebrew Szene, wich makes me sad.


Each Programm is different but it really doesn't hurt to keep some basic controlls for the most important stuff. Some programms do this already which is a good thing and overall it works better than on the old GP2X which it's limited Controll options.

 

[Nardella]

In case this de-facto standard was not followed confusion at the player's end could be guaranteed.

Just a neat bit of trivia. This was absolutely not a de-facto standard. Video console builders typically have very strict rules for this kind of thing. There are many other things that are regulated. To name a few:


Font size


Order of options in a pause menu


Length of time between system start-up and game-play


The size and shape of images used in button config menus


Loading screens must not be longer than a certain amount of time and must contain an animated graphic

 

[slaeshjag]

I don't see them as evil. Give me a standard and I'll try to stick to it.

 

[WizardStan]

Standards aren't evil. They can be but there's nothing inherently wrong with creating a standard. We've got lots of standards already, some were formalized (PXML) and others just kind of organic (Zaxxon HF6a3).


The problem with a control standardization is that, even though it has been discussed many times, no one has actually created any sort of formal RFC on the idea. Without any guideline, developers just use whatever makes sense to them at the time. You want a standard interface? Actually propose one, not this "which do you prefer". You're well on your way, but if you're asking for comment between different proposals we'll be in meetings forever. I've been in those meetings. I've stopped coming to my boss with "we can do A or we can do B" because we discuss A and B forever: now I tell him "I'm planning to do A, but B is also an option", then we only talk about it for a little bit. Usually we do A, sometimes we switch to B, but in every case there's less discussion because a decision has already been made. Make that decision! Formalize the proposal, make sure everything is accounted for, and ask for comments so it can be cleaned up before dumping it to the wiki and linking it to development pages.


Such a standard would merely be a strongly encouraged guideline, of course. If a developer has ideas that call for it to work differently, there shouldn't be anything stopping them. This standard would be for the developers that don't really care how it works and are likely happy that someone else has come up with a workable solution. I know I'd have been happy with a workable standard solution a long time ago. Not that I've released anything lately, but still...

 

[Caine]

I really couldn't care less to be honest. I've been playing PC games for about 25 years now. Back in the old days you would start by mashing every button at least once to see what it did. It is much more important that controls are always configurable.


There never has been a standard for this. Even on the playstation there were significant differences between the US/European "standard" and the Asian one. I think that emulators should always map to whatever layout is closest to the original hardware.


As far as homebrew is concerned. As long as I can remap it, use whatever controls fit the game best. Having a keyboard/gamepad mode and reading the buttons as a gamepad instead of specific keyboard keys is more important in my opinion as the current status quo is preventing you from remapping the keyboard.

 

[foxblock]

Just a neat bit of trivia. This was absolutely not a de-facto standard. Video console builders typically have very strict rules for this kind of thing. There are many other things that are regulated. To name a few:


[...]

Oh, I did not know that, thanks for the trivia.

The problem with a control standardization is that, even though it has been discussed many times, no one has actually created any sort of formal RFC on the idea. Without any guideline, developers just use whatever makes sense to them at the time.

Exactly and that's why I want to settle this once and for all.

You want a standard interface? Actually propose one, not this "which do you prefer". You're well on your way, but if you're asking for comment between different proposals we'll be in meetings forever. I've been in those meetings. I've stopped coming to my boss with "we can do A or we can do B" because we discuss A and B forever: now I tell him "I'm planning to do A, but B is also an option", then we only talk about it for a little bit. Usually we do A, sometimes we switch to B, but in every case there's less discussion because a decision has already been made. Make that decision! Formalize the proposal, make sure everything is accounted for, and ask for comments so it can be cleaned up before dumping it to the wiki and linking it to development pages.

Okay, I see the reasoning, but also one problem: I don't see myself in a position to form a standard for such things, because I only see one side of the medal - I am a games programmer, not an app programmer. I don't want to try to "force" (or "encourage") my ideas on other people's work I have few ideas about.


Though maybe I can try and those people can comment and suggest changes.


The three ideas posted above were just some often used schemas I found across the Pandora's library, each having it's own advantages and disadvantages.


Personally I would just go for the minimenu approach, it's already kind of established and makes sense - here is a bit of reasoning:


Using B and X for menu input makes sense as those buttons are easily reach-able when holding the Pandora (opposed to the A key). Also the layout is the same as on a Nintendo console using A and B (of the four, left button accepts, bottom button cancels).


Start for pause is well established in the console scene and therefore obvious despite the irony to press "start" to stop playing.


FN+Q should be used to provide a method of exiting a program instantly - from a PC it's already recognized as such. Select can also be used for that matter, as it usually has no function applied to it already - it's also located in the centre and directly accessible (contrary to ESC, which might not be recognized immediately).


Also for a button in emulators to open up the overlay menu (for settings, save states, etc.) Space should be used. While the button itself does not immediately make sense, it's still the biggest (and therefore most prominent) non-gamepad button on the Pandora - action buttons as well as Start/Select should not be used as they have a console specific function in at least one emulator each.


This is what I propose as THE SOLUTION (or whatever).

[...]

I agree with you completely, but the fact is that not all developers are able to do it or simply don't do it.


Then there are also applications, which can not or want not use gamepad input, but still want to use the Pandora specific controls.


Also default settings, there is no need to change the controls when the default ones are already perfect.

 

[EvilDragon]

While it would be nice, it is probably hard to achieve.


No other system managed to really do that so far (well, except for the iPhone, but it only has one button).


Even on the PSX / PS2, etc.


I'm RPG player, and each RPG maps cancel, menu, etc. to different buttons.


Sony keeps the buttons consistent, but not 3rd party games... so while we can suggest standards, this does not assure everyone uses them.


But suggesting them and using them in the OS really makes sense.

 

[pmprog]

I think one of the problems for this is that people are porting a lot of stuff, not writing them, so they end up outside of your "Pandora Standard"

 

[foxblock]

Sony keeps the buttons consistent, but not 3rd party games... so while we can suggest standards, this does not assure everyone uses them.

Well having a standard we can encourage people to follow is still better than having none - especially in this close community where it's much easier to actually talk with the devs and create a mutually accepted solution (it's not like we have hundreds of third party developers ).

 

[foxblock]

I think one of the problems for this is that people are porting a lot of stuff, not writing them, so they end up outside of your "Pandora Standard"

No, they don't. Well actually, not all of them do.


Porting software properly is much more than just compiling the code and getting it to run the target hardware. Sure that's the most important part, but the subtle difference between good and bad ports is how well they adapt to the new system.


Meaning when porting software you can try to ensure they use the Pandora-specific controls wherever possible, or change resolution so you don't get black bars, etc.


Changing the controls (for this matter) obviously requires one to actually dig through the code and find the places values need changing. That's a boring and cumbersome (depending on the spaghettiness of the code) task, but it's always nice to see a dev going that extra mile and while they do, following above written standard is even nicer.


That might not be possible every time, but as WizardStan wrote, this "standard" should not be forced on people, it should be encouraged to be followed when possible (so new users don't have to read every manual - which they usually don't do anyway - and still "get" what they have to do).

 

[Darkknight512]

I think the most important thing is making a standardized way to configure buttons, maybe inside of the PND spec there is a control configuration program that will be on every PND that launches a full screen app. Somewhat like the "suggested clock" menu we get in some PNDs.

 

[gadgetoid]

I lamented the lack of standard button configurations at first, but as soon as you delve into emulation it all goes to pot anyway.


What continues to irk me is that I can select items in the menu with the D-Pad, but have to hit enter to run them. But that's what I get for insisting to use Xfce instead of mini-menu.


Lack of consistency is definitely one of my biggest gripes with the Pandora*, it's a standard development target... it could be so very easy to use. But, instead, it's all over the place. I also find minimenu intolerable... sorry! It's a great alternative GUI, but I find it even less easy to use than simply firing up apps from the Xfce menu.


The minimenu way gets my vote, anyway!

 

[bismuthdrummer]

I don't know that comparing the Open Pandora to other systems in this case is fair since our software is mostly open source and therefore can be changed. If we have a label for the standard (OPC compliant, or whatever), then the ability to distinguish between standard and non-standard games will become easy.

 

[Caine]

Also default settings, there is no need to change the controls when the default ones are already perfect.

Perfection is in the eye of the beholder. If one of your buttons ever breaks then your perfect mapping goes straight out of the window, to name just one example. You claim A to be more difficult to reach, but many people place their thumb over both A and B and rock it back and forth to quickly strike those keys.


Perhaps this should be handled at the level of a programmatic API instead. E.g. have configurable "constants" VK_MENU, VK_SELECT, VK_CANCEL, VK_QUIT, etc... which can be set by the user.

What continues to irk me is that I can select items in the menu with the D-Pad, but have to hit enter to run them.

Makes perfect sense to me. The D-Pad is nothing more than the arrow-keys on your desktop. Enter has always been the confirm button and the game buttons do not exist. I.e. the Pandora doesn't really know that they are game controls, as far as it can tell it's just a regular keyboard (at least for the common abstractions at the software level).

 

[foxblock]

Perfection is in the eye of the beholder. If one of your buttons ever breaks then your perfect mapping goes straight out of the window, to name just one example. You claim A to be more difficult to reach, but many people place their thumb over both A and B and rock it back and forth to quickly strike those keys.

So far everyone I have spoken to found the B key easier to reach than the A key.

Perhaps this should be handled at the level of a programmatic API instead. E.g. have configurable "constants" VK_MENU, VK_SELECT, VK_CANCEL, VK_QUIT, etc... which can be set by the user.

That sounds like a good idea, though I have no idea how hard to implement and establish that would be.

What continues to irk me is that I can select items in the menu with the D-Pad, but have to hit enter to run them.

Makes perfect sense to me. The D-Pad is nothing more than the arrow-keys on your desktop. Enter has always been the confirm button and the game buttons do not exist. I.e. the Pandora doesn't really know that they are game controls, as far as it can tell it's just a regular keyboard (at least for the common abstractions at the software level).

It does not make perfect sense on the Pandora. Sure the Enter key still is the Enter key, but we also got those action buttons, which, when holding the Pandora with both hands, are easier to reach than the Enter key and when thinking of the Pandora as a gaming device are intuitively pressed to navigate in menus (at least I find myself pressing B quite a few times before I hit Enter).


The Pandora is also an office computer and re-assigning the function of the Enter key to one of the action buttons in XFCE might not be the best idea, but in some games or emulators it makes much more sense, because the user does not think of the Pandora as a computer at that point (and this use-case is what I was mostly aiming at here).


The Pandora does not need to know that those are game controls, but the application does need to know how the Pandora looks and feels and should select the best method of input for that case (which in most cases does not involve the keyboard).


As usual, the best way is subjective, but a standard always is to some degree, it might just be trying to get most use-cases in one document and most users satisfied. And as most usually is not all, everything still should be configurable, but we could at least have a default standard for new users to get into the device.

 

[Caine]

So far everyone I have spoken to found the B key easier to reach than the A key.

I had this thread in mind when I wrote that. I did not recall only so few people voted, but still 50-50. I will admit that it's not exactly the same issue.

Perhaps this should be handled at the level of a programmatic API instead. E.g. have configurable "constants" VK_MENU, VK_SELECT, VK_CANCEL, VK_QUIT, etc... which can be set by the user.

That sounds like a good idea, though I have no idea how hard to implement and establish that would be.

I'm not entirely sure either. There would need to be some sort of highly accessible interface (from various languages) which could be queried for those values and it should be easy to compare those to keys used in e.g. SDL and similar libraries and frameworks.

It does not make perfect sense on the Pandora. Sure the Enter key still is the Enter key, but we also got those action buttons, which, when holding the Pandora with both hands, are easier to reach than the Enter key and when thinking of the Pandora as a gaming device are intuitively pressed to navigate in menus (at least I find myself pressing B quite a few times before I hit Enter).

We are still in the stage that most software consists of quick ports. As such, the applications are most definitely not aware of the Pandora layout. It's not ideal, but it is the reality we are dealing with. In the past I have argued to keep the keyboard layout as close to a regular keyboard as possible, because I expected that few ports would take a serious effort to change keys and bindings. I don't think that expectation turned out to be incorrect.

but in some games or emulators it makes much more sense, because the user does not think of the Pandora as a computer at that point (and this use-case is what I was mostly aiming at here).

I fully agree with you on this. Luckily, emulators are the typical applications that do seem to get this kind of attention during porting.

but we could at least have a default standard for new users to get into the device.

I agree with Wizardstan here. Just define it based on your own insight and people will fire at it a little and either accept or reject it. You can start endless debates about it, but in the end the first working proposal is most likely to win and it's better than nothing.

 

[WizardStan]

Perhaps this should be handled at the level of a programmatic API instead. E.g. have configurable "constants" VK_MENU, VK_SELECT, VK_CANCEL, VK_QUIT, etc... which can be set by the user.

That sounds like a good idea, though I have no idea how hard to implement and establish that would be.

If they're using SDL, then checking for the existence of VK_SELECT, etc... is dead simple, and the virtual keys are easy to modify at program start.

 

[Ziz]

In the German Chat we got some nice ideas to define a possible defacto standard, which every user is able to change. We just could use some linux environment variable. The advantage would be, that it is very easy to read them for every programming language and equally easy to change.


Furthermore could the next Hotfix Release get some default values with just some lines of code. ;-)

 

[foxblock]

I had this thread in mind when I wrote that. I did not recall only so few people voted, but still 50-50. I will admit that it's not exactly the same issue.

Well it shows the crowd is not unanimous, but it also shows all people put B (the cancel, harder to reach key) on either A or X and A on B or X, so (and I guess you could interpret that differently) it actually proves my point

I agree with Wizardstan here. Just define it based on your own insight and people will fire at it a little and either accept or reject it. You can start endless debates about it, but in the end the first working proposal is most likely to win and it's better than nothing.

I did so here, but I might not have made that entirely clear, I will edit my first post to reflect that change. For the record, that's the layout I am proposing:


B - Confirm


X - Cancel


START - Pause (in game)


Fn+Q (ESC) - Exit


Select - Exit / Menu (as an alternate to Fn+Q)


Space - Overlay menu in emulators