bzar
A Commando
WizardStan said:If it is done correctly, going through the OS rather than directly to the hardware, then it is possible and very easy to set the A button to always return the key code for the A button when the A button is pressed, regardless of where the A button is.B-ZaR said:Awakening said:Wouldn't it be nice if we can somewhere in the OS select the Accept and Back buttons?
Hmm, aliases for the buttons...
You could set any key on the keyboard to return the key code for any other key regardless of what it actually said on the key itself.
You could create mapping files that are loaded just before your program and unloaded after it. Imagine a mapping file that mapped the enter key to the same key code as the Start button that is loaded as part of the SNES emulator start. Then you can pause by pressing either the Start button or the Enter key.
This already exists and has been discussed many, many times, and even brought up in this very thread! Why is there still any hesitation or debate about it?
I meant something like BUTTON_OK define that actually maps to BUTTON_A or something. This BUTTON_OK definition could be used by application developers to implement an "OK" functionality. Similarly, there could be a BUTTON_BACK. I think this is what the OP was after. The "OK" button should be the same between apps whatever it is, preferably the "BACK" button as well. The OP is concerned that because the button layout does not give a logical choice for the "main button", developers will choose different ones. Some based on the letters and some based on the button's location. If there was a BUTTON_OK alias devs could all use that to signify "that button that is pressed to do stuff" and it would nicely map to that same physical button in all applications.
Last edited by a moderator: