4.1 Specifications Requiring Extreme Input
Due to the possibility of shortening the product lifetime or causing damage to the product, as well as leading to injury to the user, Nintendo recommends that applications do not require extended periods of extreme input when using the Touch Screen or other input devices, such as continuous, frequent, or excessive pressure on the input devices.
In particular, the START Button (as well as the SELECT and HOME Buttons) is not as durable of a button as it was on previous platforms, so specifications that make the user rapidly and repeatedly press the START button are prohibited. It is also prohibited to give some special effect to the act of pressing the START Button in short intervals such as double-clicking. We recommend that you not use the START Button as one of your application’s main operations, but as a means to pause, enter a menu screen, or perform some other supplementary role.
If your application is classified as a Virtual Console title, the prohibitions against rapidly pressing or double-clicking the START Button do not apply, because your application follows the original specifications.
Input Devices
Touch Screen
START
SELECT Button
HOME Button
Rapid and Repeated Pressing
Virtual Console
Product Lifetime
Safety
4.2 Capturing Images with Outer Cameras for Use in Stereoscopic Display
When the left and right outer cameras capture stereoscopic images, they must use the same settings: these include effects, the automatic exposure feature, and the frame rate. If the left and right outer cameras are configured differently, there is a possibility that a large discrepancy may occur between the left and right images, resulting in an inappropriate stereoscopic display. Inappropriate stereoscopic display may also result from the surrounding environment or from use of variable frame rate, but this is acceptable so long as the left- and right-camera settings are the same.
On the other hand, the following functions control the behavior of the automatic exposure and automatic white balance features to account for differences in the background between the left and right outer cameras. These functions deliberately set different values for the left and right outer cameras, so you do not need to set the same value for the left and right outer cameras using these functions.
- nn::camera::CTR::SetAutoExposureWindow function
- nn::camera::CTR::SetAutoWhiteBalanceWindow function
Input Devices
Outer Cameras
Capture
Stereoscopic Display
nn::camera::CTR::SetAutoExposureWindow function
nn::camera::CTR::SetAutoWhiteBalanceWindow function
4.3 Microphone Input Detection
When detecting microphone input, you must take the guaranteed microphone input range and prohibited detection ranges into consideration. However, it is acceptable to ignore these ranges if you are using the microphone but not attempting to detect microphone input.
The upper and lower bounds of the guaranteed input ranges are defined as constants in nn::mic::CTR. Note that by default microphone input is clamped so as to use values within the guaranteed input range.
You can get the range(s) of values representing the prohibited detection range with the nn::mic::CTR::GetForbiddenArea function. If the microphone registers input values in this range, you must treat it as noise and not detect it as microphone input.
Sampling Type | Guaranteed Microphone Input Range |
---|---|
SAMPLING_TYPE_8BIT | 27 to 228 |
SAMPLING_TYPE_16BIT | 7105 to 58415 |
SAMPLING_TYPE_SIGNED_8BIT | -101 to +100 |
SAMPLING_TYPE_SIGNED_16BIT | -25663 to +25647 |
Microphone
Input Determination
Guaranteed Input Range
Prohibited Detection Ranges
Noise Component
nn::mic::CTR::GetForbiddenArea function
Sampling Type
SAMPLING_TYPE_8BIT
SAMPLING_TYPE_16BIT
SAMPLING_TYPE_SIGNED_8BIT
SAMPLING_TYPE_SIGNED_16BIT
4.4 Preventing False Detection of Microphone Input
To avoid any problems, applications that use the microphone must implement some means of dealing with erroneous microphone input detection. You might use means similar to the following.
- Do not output sound through the speakers when the microphone is in use.
- Provide an option that lets the user adjust the microphone sensitivity.
- Provide an option that lets the user adjust the threshold used for microphone input detection.
Acoustic feedback can occur if you continuously play back audio input from the microphone through the speakers in real time. This is not limited only to cases where audio taken as input to a Nintendo 3DS system's microphone is immediately played by speakers on that same system. It is also possible for feedback to occur during voice chat, when audio makes a round trip to the partner's Nintendo 3DS system before being played by speakers on the original system.
You must take some measure to prevent acoustic feedback if your application will be playing back audio input obtained from the microphone in real time for an extended period of time. Possible countermeasure 2 above, letting the user adjust the microphone sensitivity, can also be effective in preventing feedback.
Microphone
Erroneous Input
Feedback
Voice Chat
4.5 Gyro Sensor Power
If the application creates one or more instances of the nn::hid::CTR::GyroscopeReader class, then the gyro sensor power turns on and consumes more power than when the gyro sensor power is off. Consequently, if the gyro sensor power is always on, the system battery life is reduced by about 2% to 3% when compared to always having it off.
For this reason, applications that do not use the gyro sensor must not create an instance of the nn::hid::CTR::GyroscopeReader class.
Even for applications that use the gyro sensor, the nn::hid::CTR::GyroscopeReader class instance should be created, if possible, only just before using the gyro sensor. If possible, Nintendo also recommends deleting the instance of the nn::hid::CTR::GyroscopeReader class in scenes where the gyro sensor is not used. However, considering that gyro sensor sampling takes a maximum of about 160 ms to start after an instance of the nn::hid::CTR::GyroscopeReader class is created, there is no need to excessively create and delete instances in short intervals.
Starting with the CTR-SDK 7.x series, you can check whether the application uses the gyro sensor by checking whether "NINTENDO:Gyroscope" is displayed in the list of middleware on the Master Editor's Basic Information (CCI) tab. If "NINTENDO:Gyroscope" is not displayed, the application does not use the gyro sensor at all.
Gyro sensor
nn::hid::CTR::GyroscopeReader Class
Power consumption
4.6 Prohibition of Accelerometer Calibration
The Nintendo 3DS system is equipped with a feature that allows users to calibrate the accelerometer zero point. You can use this feature any time the HOME Menu is displayed—even while an application is suspended—by holding down both the B Button and Y Button for 3 seconds. If the accelerometer zero point is calibrated from the HOME Menu, the values obtained from the nn::hid::CTR::AccelerometerReader class's Read and ReadLatest functions are corrected values.
Because this feature allows users to calibrate the accelerometer at any time they choose, applications must not implement their own independent accelerometer calibration. However, when accelerometer drift (particularly due to any short-term temperature changes) could have a major effect on application behavior, contact Nintendo at support@noa.com if there is a need for your application to implement its own independent calibration mode.
Accelerometer
Accelerometer drift
Accelerometer zero point
Calibration
HOME Menu
nn::hid::CTR::AccelerometerReader class
nn::hid::CTR::AccelerometerReader::Read function
nn::hid::CTR::AccelerometerReader::ReadLatest function