This chapter describes the system buttons, excluding the HOME Button. The HOME Button is described in chapter 2.5 HOME Button.
2.4.1 Shared Items for All Buttons
There are cases where one button press may be registered multiple times. This often happens when a button is pressed softly and slowly, at the lowest limit of detection. To help prevent this, the system is designed to sample button input only once every 4 milliseconds. It can also be effective on the application side to employ measures such as setting the button read frequency to once every frame.
No required guideline items.
2.4.2 SELECT Button
The Nintendo 3DS provides a SELECT Button to maintain compatibility with TWL systems. However, future Nintendo 3DS-compatible systems are not guaranteed to have a SELECT Button. As a result, it is prohibited for applications to prompt the player—either on-screen or in the manual—to press the SELECT button.
If you want to allow players to press the SELECT Button in place of the START Button for some reason, which could be related to how players hold the system or how easy it is to press the SELECT Button, it is acceptable to explain to players that the SELECT Button and START Button can be used for the same functions.
Applications that use the standard CTR-SDK cannot distinguish between the START Button and the SELECT Button. As a result, the START Button can always be used as an alternative to the SELECT Button. The above restriction applies to explicit instructions to press the SELECT Button.
There are some exceptions: for example, Virtual Console, 3D Classics, or other applications in which the feeling of the controls being identical to that of past games is especially important; or, applications whose playability would be severely impacted by the different control feel on FTR systems resulting from the different button placement on FTR. In such cases, Nintendo may allow use of the SELECT Button, with conditions.
2.4.2.1 Prohibited Text for Features That Use SELECT
Guideline Item |
There must be no mention of features that use SELECT in applications, manuals, packages, or anywhere else.
|
---|---|
Software to Be Tested |
All applications.
|
Exceptions |
If the following cases apply:
|
Test Method |
Look for references to SELECT in the application, manual, packaging, and elsewhere.
|
Pass/Fail Determination |
Passes if SELECT is not mentioned anywhere.
|
2.4.3 POWER Button
The purpose of the POWER Button is to display the POWER Menu immediately upon being pressed. Therefore, when the system detects a POWER Button press, the application must immediately call both the nn::applet::ProcessPowerButton function and the nn::applet::WaitForStarting function to display the POWER Menu. After control returns from the nn::applet::WaitForStarting function, complete the shutdown process in compliance with the Programming Manuals and Function Reference Manual. Within this section, “immediately” means “in less than three seconds.” When the POWER Button is pressed and held down for at least three seconds, the forced shutdown process begins. This process is provided as a remedy for critical situations such as system lockups, and is not intended to be used to shut down the system under normal circumstances. Consequently, display the POWER Menu immediately to prevent the user from inadvertently holding the POWER Button down.
If the POWER Button is pressed during write operations that will take three seconds or more to complete, the application must display the POWER Menu without waiting for the write operations to complete. If the application is formatting save data, it is acceptable to display the POWER Menu after the application has finished formatting; this is the only case where it is acceptable to wait for the operation to complete. In this case, the application does not need to temporarily stop writing data. Note, however, that the application cannot accept any input or display any other screens after the POWER Menu is displayed.
If the POWER Button is pressed while the application is creating an extended save data archive, then depending on the SD card it may take up to 10 seconds or more for the POWER Menu to be displayed after the nn::applet::ProcessPowerButton function is called. As long as the application calls nn::applet::ProcessPowerButton promptly, you do not need to implement any special handling for this symptom.
The forced shutdown timeout starts counting down from when the POWER Button was pressed. Once the POWER Menu is displayed, the application will be unable accept any input or display any other screens.
Also note that applications cannot display the POWER Menu in the following cases.
- While the system is preparing to launch an application (during the display of the Nintendo 3DS logo)
- While the system is transitioning to any library applet
While the system is preparing to launch an application, the POWER Menu does not appear even if the POWER button is pressed. However, you must ensure that the POWER Menu will display after logo display completes by evaluating the close requests according to the instructions in the function reference pages for the nn::applet::Enable* functions. Although the system will shut down without displaying the POWER Menu if the POWER button is held down during the logo display, applications do not need to be concerned about this behavior.
Also, POWER Button input cannot be detected in the following cases unless the POWER button is held down for at least three seconds:
- If the POWER Button is pressed while transitioning to a library applet such as the software keyboard
- During a software reset (call to nn::applet::RestartApplication)
Applications do not need to take any special measures regarding this behavior.
2.4.3.1 Supporting POWER Menu Display
Guideline Item |
Applications must display the POWER Menu promptly after detecting a POWER Button press.
|
---|---|
Software to Be Tested |
All applications.
|
Exceptions |
When performing any of the following actions:
|
Test Method |
|
Pass/Fail Determination |
Passes if all of the following conditions are met.
|