Standardized Controls

[foxblock]

I'd avoid putting || in an environment variable. It can make make setting and using it less than trivial. Space separated and it automatically becomes parseable in pretty much everything

export VK_CONFIRM="VK_PANDORA_B VK_ENTER"

for KEY in $VK_CONFIRM

do

  echo $KEY

done

Yes, that makes much more sense.


@Caine: I support most of your proposal, especially the Standard definition at the end, but what's the reason for binding the "meta" keys directly to virtual keys?


Your current proposal might be easier to use, but would only work for people who have not re-mapped their keys (for example to use Christoph.Krn's mapping).


(Also VK_L2 should be VK_R1)

 

[WizardStan]

So if we have a definition such that


VK_CONFIRM=VK_ACT_B


and we can also define


VK_ACT_B=VK_END


then we have a few problems: how do we implement it such that VK_CONFIRM is updated after VK_ACT_B, and how do we prevent circular definitions? (ie, CONFIRM=B and B=CONFIRM)


edit: or we could just keep it simple and not allow that. Meta keys cannot be defined by other meta keys. If you want A to be END and cancel to also be HOME then you must have two definitions: VK_CANCEL=VK_HOME and VK_ACT_A=VK_HOME?

 

[foxblock]

Well first of all VK_CONFIRM would be set by an application to edit the "control standard" and VK_ACT_B should be modified by the system (or whatever keeps track of the keyboard mapping).


Then if one changes the mapping of B (to LeftMouseClick instead of END), VK_CONFIRM does not need to be changed, it will still refer to the same physical key, but the application using the envar will lookup VK_CONFIRM, then lookup VK_ACT_B, will find LeftMouseButton (or whatever key is mapped to B ) and compare that to the key-code input.


Circular mapping are indeed a problem, though - a solution could be to simply ignore "meta-keys" (VK_CANCEL, etc.) in action button envars (VK_ACT_B, etc.), I don't know whether that should be done on an system or application level.

 

[foxblock]

1) is unlikely to be very helpful in an open environment such as the Pandoras, but 2) can be used to reduce remaining problems and make 1) successful anyway. I hope this makes a little more sense. It splits the potential success of this standardized controls effort here into standardization, graphic design, software design, and psychology, (all part of usability) and might still be difficult to understand. Please tell me if something is unclear.

Thanks for that post, it was much more conclusive and read-able than the ones before.


As I said before, I agree with you on the matter of hints, but you must realize what we are doing here can be separated and still has a valid application (aka a default mapping for apps not using hints, default mappings in envars accessible by every program, etc.)


I went forward and created a new thread for the matter of discussion a set of standardized hints, please continue the discussion about hints there:





Maybe a moderator can also move some posts (or parts of them over).


Thank you.

 

[Caine]

@Caine: I support most of your proposal, especially the Standard definition at the end, but what's the reason for binding the "meta" keys directly to virtual keys?


Your current proposal might be easier to use, but would only work for people who have not re-mapped their keys (for example to use Christoph.Krn's mapping).


(Also VK_L2 should be VK_R1)

The idea was that users could opt to use different buttons in menus if so desired, rather than hardwiring it to the gaming controls, e.g. someone might prefer enter for accept yet have B bound to end. It does create the issue that you now have two aliases for the same key, but if devs use the correct virtual keys in the correct context then these two buttons can be decoupled from eachother.


@L2, duhhh. fixed

 

[Christoph.Krn]

I went forward and created a new thread for the matter of discussion a set of standardized hints, please continue the discussion about hints there:

Ungh, I would actually have preferred if instead I had just been shouted at to "Shut up and open your own thread!". This can't turn out well.


Ah well, nevermind.

 

[Caine]

Ungh, I would actually have preferred if instead I had just been shouted at to "Shut up and open your own thread!". This can't turn out well.


Ah well, nevermind.

I don't think that is the message at all. Your observations about standard hints are most valid. From a technical viewpoint however, it is an entirely different challenge.


I think we should do both. Have better standard controls and a better way to decouple controls from a specific mapping such that a user can set global preferences to which applications can adhere. But we should also develop a more uniform way of communicating this to the user.


Having a good way to provide hints will aid users in learning the control scheme and to deal with those applications which do matters otherwise and as you have pointed out yourself, there are many valid reasons for not (fully) adhering to the (optional) standard.

 

[Christoph.Krn]

Your observations about standard hints are most valid. From a technical viewpoint however, it is an entirely different challenge.

I'm aware of that.


What I wrote was not intended to be a discussion starter and in that role it is not very useful. One could say that some chances are now reduced (incentive!).

 

[Silent-Hunter]

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

Not me. A is easier for me.

 

[milkshake]

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

I would agree, through use of lots of consoles i.e. snes, playstation and xbox 360 the button in the position of b on the pandora always is the back/cancel button and it feels natural (unless u have a playstation and you are from japan that is )

 

[foxblock]

The idea was that users could opt to use different buttons in menus if so desired, rather than hardwiring it to the gaming controls, e.g. someone might prefer enter for accept yet have B bound to end. It does create the issue that you now have two aliases for the same key, but if devs use the correct virtual keys in the correct context then these two buttons can be decoupled from eachother.

Hmm, well I think those functions should be bound to physical keys instead of virtual ones (or key codes), to be not confusing and to always work no matter the keyboard mapping (which is an advanced functionality though).


Also using the Pandora's action keys would work as well as using the normal keyboard (including shift, enter, etc.) - this obviously is slightly trickier for the dev to implement as he has to lookup certain variables twice (to resolve what button VK_ACT_A actually refers to). Also chaning the mapping of one button would not invalidate the menu keys (as the "accept" action still points to the same physical button), which seems desirable.

Ungh, I would actually have preferred if instead I had just been shouted at to "Shut up and open your own thread!". This can't turn out well.


Ah well, nevermind.

To be blunt: You could have noticed that for quite a while now, but you kept posting follow-ups...


Not meaning to attack you or diminish your ideas, but I think we can separate this pretty well and expressed so repeatedly.


Oh and why post (good) ideas, if you don't want them to be discussed - you did well in bringing this matter to attention and many people agreed this needs to be discussed, so a separate discussion can only do good (or die without result, but that's not too bad either).


If you would like the "ownership" of the other thread (read: the first post), I am pretty sure it can be arranged using some dark moderator voodoo.

I would agree, through use of lots of consoles i.e. snes, playstation and xbox 360 the button in the position of b on the pandora always is the back/cancel button and it feels natural (unless u have a playstation and you are from japan that is )

Yes, as written before, this is an extreme matter of taste. Some people prefer B, some A, some another key - you cannot please everyone, which is why it's almost required to supply a small interface to change the mapping (without having to deal with setting envars through a terminal).


Also a slight correction: The Pandora B button shares the position with the SNES A button, which is used for "accept" on that device (same for Pandora X and SNES B - used for "cancel"). This, as well as other Nintendo consoles, is the device I drew inspiration from - the Sony and Microsoft consoles are the ones deviating from that schema.

 

[ZXDunny]

I support foxblock's layout and functionality with only one reservation, and it should be borne in mind that I've not actually tried to code this (yet - my current port is underway).


I'm almost certainly going to have to read the buttons via hardware rather than the SDL key event values. This makes FN+Q quite a bit more complex, as there are two ways to activate the Esc key in XFCE - you can either press FN+Q together, or you can press FN and then press Q later, having let go of the FN key. It's not hard to implement this behaviour, but it is a pain in the ass. To this end, I'm going to refuse to support using the Esc key to exit the game - I'm going to have START to pause, with a press on B to get back to the main game menu (and on-screen instructions to that effect), where another press on B will exit the game. a second press of START, once paused, will resume the game, as will a press on A.


The reason I'm probably going to read the button hardware directly is because if I do not, and I choose, say, A to fire, I'll be checking the HOME key as the fire button. Odds are that some idiot will have remapped their key layout - there's instructions on how to do that on this very forum, I believe, and some muppet in this thread is threatening to do just that - so that the fire button will end up on a nub somewhere, and that throws my mappings out completely, especially if I proclaim on the instructions page that "A" fires your gun.


As for the rest of Foxblock's control layout, I'm behind it 100%. I detest using enter to select menu items, so I shall prevent users from doing so. And it doesn't matter how much people bitch and moan about it - I'm going the extra mile to use the Pandora's gifts of dedicated controls and taking the time to tailor my ports to the platform properly.


D.

 

[Fworg64]

If we are to allow multiple keys, then I agree with WizardStan to use a space-separated list.


Ok. So let's define which keys we all need. Here is my first take on this.


...

I place my vote for a standard, as this one.


Also as an addition, i believe this is implied however, VK_MENU_UP =up and VK_MENU_DOWN =down.


However a less obvious one that i still stand by is pagedown functions for the menu's on R and L, I feel this is intuitive, at least its used on the Xbox 360. eg VK_MENU_PAGEDOWN = Shift_R and VK_MENU_PAGEUP = Control_R.

 

[Christoph.Krn]

Odds are that some idiot will have remapped their key layout - there's instructions on how to do that on this very forum, I believe, and some muppet in this thread is threatening to do just that - so that the fire button will end up on a nub somewhere, [...]

Nah, that was just extremely badly explained. This was for after full user customization is established, and for a subset of scenarios. It was one part of a bigger idea.

 

[Caine]

Odds are that some idiot will have remapped their key layout -...- so that the fire button will end up on a nub somewhere, and that throws my mappings out completely, especially if I proclaim on the instructions page that "A" fires your gun.

That is exactly a reason to introduce the virtual key environment variables. In that case you can just read an environment variable to discover which key is bound to VK_ACT_A (or whatever we will call it). This way you can bind "directly" to a game key, yet the user can still change his/her mapping on the desktop without breaking the game.

 

[WizardStan]

The reason I'm probably going to read the button hardware directly is because if I do not, and I choose, say, A to fire, I'll be checking the HOME key as the fire button. Odds are that some idiot will have remapped their key layout - there's instructions on how to do that on this very forum, I believe, and some muppet in this thread is threatening to do just that - so that the fire button will end up on a nub somewhere, and that throws my mappings out completely, especially if I proclaim on the instructions page that "A" fires your gun.

Unless, as was suggested, the game buttons get virtual keys as well which are then mapped to their respective underlying keys. If someone wants to redefine Left on the right nub as Home, and make the A button enter or something, then they better make sure they're redefining VK_ACT_A as "ENTER" or they'll have no one but themself to blame for their problems.


The other benefit to being able to redefine the game pad buttons is that if the user wants to change the configuration into something more familiar they can do so and simply redefine where the new ACT_A/ACT_X are and any developer who follows the standard will be able to say "Press A to jump" and it will still be correct. If you look directly at the hardware instead, what you assume to be A will have changed.

 

[Neelix]

I support foxblock's layout and functionality with only one reservation, and it should be borne in mind that I've not actually tried to code this (yet - my current port is underway). I'm almost certainly going to have to read the buttons via hardware rather than the SDL key event values. This makes FN+Q quite a bit more complex, as there are two ways to activate the Esc key in XFCE - you can either press FN+Q together, or you can press FN and then press Q later, having let go of the FN key. It's not hard to implement this behaviour, but it is a pain in the ass. To this end, I'm going to refuse to support using the Esc key to exit the game

Erm... shouldn't both of these methods produce the same key code? In any case, if I understand this correctly, you wouldn't be handling the escape key directly if you used this schema, just the virtual key that happens to be bound to it, so your program would be ignorant of whether it was using the escape key or something else entirely.

I detest using enter to select menu items, so I shall prevent users from doing so. And it doesn't matter how much people bitch and moan about it - I'm going the extra mile to use the Pandora's gifts of dedicated controls and taking the time to tailor my ports to the platform properly. D.

Considering that the Pandora has both keyboard and game controls, actually preventing the use of Enter to select an item in a menu is to my mind going the extra mile to prevent the use of Pandora's gifts of a full qwerty keyboard, and utterly fails at the goal of tailoring ports to the platform properly.


Seriously, as someone who comes from a PC background and has had very little prior console gaming experience I find programs that don't react to enter on a menu screen to be very counter-intuitive. The first time I fired up some of the games on the pandora, I couldn't work them at all because it didn't occur to me to use the gaming buttons for menu selection. I had to force quit then check the documentation. Even now that I'm somewhat used to the concept, Enter is still what I tend to hit first.


- Neelix