I have already stated several times why the above layout is not a good idea: compared to the Pandora layout, the X and A are swapped. That means that there are two options, none of which are desirable:
- either we swap the keycodes too (so Home and PageDown are swapped), which would make the positioning of Home-End-PgUp-PgDn very illogical and which would break games that use the ABXY keys as a secondary dpad (e.g. for weapon aiming), since you would need to press the south button to aim left and the west button to aim down.
- or the keycodes are not swapped, only the labels. But then if a Pandora application/game says "press X", you have to press "A", and when it says "press A", you have to press "X".
Of course none of this is an unsurmountable problem, we could eventually learn to live with it. But why would we purposefully break backwards compatibility in such a confusing way?
We're not breaking backwards compatibility by having A and X be in different places. All we're doing is referring to the button differently. The functionality still works. And, assuming you don't swap keycodes, (which we totally should not swap the keycodes) then the buttons are still in the same place for gameplay purposes. Then, you only need to learn 2 buttons that are swapped, which is actually a lot less effort than learning, say, for SNES on the Pandora that (legend: Pandora = SNES) A = Y, Y = X, X = B, and B = A.
It would be pretty bad practice in my opinion to use those words to describe the buttons in documentation. I would recommend using the actual symbols (Δ Π Ω X), there should not be any reason to resort to spelled out forms (we don't talk about the A Bee Ex Wye buttons either). Unicode characters should always be available, unless maybe when you're porting some old game which uses a built-in ASCII-only font. In those rare cases you could use descriptions like Triangle Square Circle Cross, or maybe use some kind of ASCII art approximation like
, ___ _ \/
/_\ | | _( )_ /\ or in one line: /\ ][ () ><
That actually hurts your argument. people aren't going to use multiline in text, so they would use one-liners, and while the one-liner for Delta could likely be understood, the one-liners you put for Pi and Omega look nothing like them and would cause confusion. Also, side question: Why did you use >< for Chi instead of X? That is harder for people to see as well.
-God Ginrai
Forget about ASCII art, just use the actual symbols.
Don't you agree that having to learn a mapping from {A,B,X,Y} to {A,B,X,Y} is harder and more confusing than learning a mapping from {Δ,Π,Ω,X} to {A,B,X,Y}?
Compare:
Using the layout:
Z
Y C
X B
A
we get:
Pyra → Pandora: X → A, Y → Y, B → B, A → X
Pyra → Nintendo: X → Y, Y → X, A → B, B → A
Pyra → Nintendo64: X → B, Y → CL, A → A, B → CD, Z → CU, C → CR
Pyra → Sega Genesis: perfect match
Pyra → Dreamcast: perfect match
Pyra → PlayStation: X →
□, Y →
△, B →
◯, A → X
Using the layout
Σ
Δ Ψ
Π Ω
X
Pyra → Pandora: Π → A, Δ → Y, Ω → B, X → X
Pyra → Nintendo: Π → Y, Δ → X, Ω → A, X → B
Pyra → Nintendo64: Π → B, Δ → CL, Ω → CD, X → A, Σ → CU, Ψ → CR
Pyra → Sega Genesis: Π → X, Δ → Y, Ω → B, X → A, Σ → Z, Ψ → C
Pyra → Dreamcast: Π → X, Δ → Y, Ω → B, X → A
Pyra → PlayStation: Π →
□, Δ →
△, Ω →
◯, X → X
Ugh. It's a mess anyway when you're doing emulation.
Still, for native applications I think having unique, Pyra-specific button labels would be neat.
