3.1 Restriction on Repeated Per-Frame Alternation Between Significantly Different Luminance Values
Alternating every frame between two colors with significantly different luminance values (such as in a flickering effect) will decrease the lifespan of the LCD module for the CTR system's LCD screens. Therefore, as much as possible, avoid the prolonged use of any such effect such that any single pixel on the screen experiences it continuously for one minute or longer. The "significantly different luminance values" stated here refer to differences where all three of the R, G, B components change by a value of 128 or larger.
Nintendo does not recommend exploiting the properties of the LCD module with the image technique of switching repeatedly between two colors to achieve a "translucent" effect. It is possible that the screen may appear to flicker when displaying such an effect if the response speed of the LCD module becomes faster than that of current CTR systems, due to changes in product specifications or the release of future CTR-compatible systems.
Graphics
LCD Module
Alternating Display
Changes in Brightness
Luminance
3.2 Applications That Do Not Use Stereoscopic Display
The amount of energy consumed in stereoscopic display mode (NN_GX_DISPLAYMODE_STEREO) differs considerably from normal mode (NN_GX_DISPLAYMODE_NORMAL).
Because use of this feature affects the length of time the system is able to operate while running off battery only, it is prohibited to use stereoscopic display mode in applications that do not generate any stereoscopic images. For the same reason, we consequently recommend that applications use the normal mode when they are not generating stereoscopic images.
Stereoscopic Display
NN_GX_DISPLAYMODE_STEREO
NN_GX_DISPLAYMODE_NORMAL
Power consumption
3.3 Supporting Stereoscopic Display
Applications that support stereoscopic display must use the nn::ulcd::CTR::StereoCamera-class functions to adjust stereoscopic parallax in response to user operation of the 3D depth slider. This is because, if the application does not use the nn::ulcd::CTR::StereoCamera class and instead implements an independent way of adjusting stereoscopic parallax, there is a possibility that the parallax adjustment may not behave as intended in future CTR-compatible systems. However, it is acceptable in the following cases for applications to either not use the nn::ulcd::CTR::StereoCamera-class functions, not allow parallax adjustment, or not be capable of changing parallax in response to user operations.
- Stereoscopically displaying the following types of content for which the parallax cannot be altered with the 3D depth slider.
- Content that is generated in advance (pre-rendered video or photos)
- Images captured with the outer cameras
- Cases where it is technically difficult to update the displayed parallax to match adjustments to the 3D depth slider, such as while the game is paused. (However, this is only permissible for a short period of time in a range that would not inconvenience the user).
- Temporarily not using stereoscopic display, as part of application progression.
- Taking content whose parallax cannot be adjusted and display it layered with content rendered in real time
Nintendo recommends not supporting the 3D depth slider in this case, because it is possible to create an unsettling stereoscopic image with a contradictory foreground-background relationship if the 3D depth slider only affects the object rendered in real time.
The fundamental purpose of the 3D depth slider is to account for variation among individual users in how much stereoscopic parallax can be viewed comfortably. It is not intended to provide application developers with more freedom or with an additional input interface. However, even if the effect is not completely identical to the Nintendo 3DS standard of parallax adjustment using the nn::ulcd::CTR::StereoCamera-class functions, it is acceptable to use the value of the 3D depth slider in the application so long as you use it for the purpose of adjusting some kind of effect related to stereoscopic display, such as in the following cases.
- Implementing stereoscopic display by applying parallax proportionate to the value of the 3D depth slider to one or more 2D layers.
- Blurring (defocusing) objects in the background or foreground to a degree depending on the value of the 3D depth slider.
You can get the value of the 3D depth slider with the nn::ulcd::CTR::Get3DVolume function. Also note that it is prohibited to compute the 3D depth slider value applied in the application by means other than the nn::ulcd::CTR::Get3DVolume function. (For example, back-calculating the 3D depth slider value from the amount of parallax is prohibited.) This is because implementations that use 3D depth slider values obtained by back-calculation may produce unintended values in future CTR-compatible systems.
Stereoscopic Display
3D Depth Slider
Parallax
Pre-Rendered Video
Outer Cameras
nn::ulcd::CTR::StereoCamera Class
nn::ulcd::CTR::Get3DVolume Function
3.4 Referencing the Stereoscopic Display Permission State
You can use the nn::gx::CTR::IsStereoVisionAllowed function to check whether stereoscopic display is currently permitted, but if you change application behavior in response to this permission state, you must only change behavior or features that are related to stereoscopic display. Also note it is prohibited to use the nngxSetDisplayMode function to change the display mode of the upper screen in response to the result returned by nn::gx::CTR::IsStereoVisionAllowed. This is because the nngxSetDisplayMode function is linked with illumination of the 3D LED, and the 3D LED is intended to inform the user of scenes where stereoscopic display is possible—not to reflect whether stereoscopic display is currently permitted.
The following are examples of acceptable changes to application behavior in response to the stereoscopic display permission state:
- Not allowing users to select modes that use the outer cameras to take 3D photos if stereoscopic display is not permitted.
- Playing a sound effect when the permission state changes.
- Adding a visual effect to the appearance of the application, without affecting any of the application's content.
In contrast, the following are examples of prohibited processing:
- Using the nngxSetDisplayMode function to change the display mode of the upper screen based on the stereoscopic display permission state.
- Using switching of the stereoscopic display permission state as a input method for controlling an in-game character.
- Changing the strength of an enemy based on the permission state.
Stereoscopic Display
3D LED
Display Mode
nn::gx::CTR::IsStereoVisionAllowed Function
nngxSetDisplayMode Function
3.5 Implementations That Disable Updating of Right-Eye Buffer When Stereoscopic Display is Not Permitted
If your application implements a means of reducing the processing load by not updating the right-eye buffer when the 3D depth slider is set to "off" or when stereoscopic display is restricted by Parental Controls, then your application must not cause inappropriate stereoscopic display if the user transitions to the HOME Menu and the permission state changes to allow stereoscopic display. "Inappropriate stereoscopic display," as mentioned here, results from a large difference in content between the left-eye and right-eye buffers. For example, cases such as having a black screen for only one eye or having images of different scenes in the left-eye and right-eye buffers fall under this definition.
Specifically, you must handle the situation mentioned above by (for example) either copying the content of the left-eye buffer to the right-eye buffer or setting both buffers to a black screen before transitioning to the HOME Menu.
You can use the following steps to check whether the application is handling it properly.
- Progress to a scene where the application does not update the right-eye buffer.
- Turn the 3D depth slider off (move the 3D depth slider all the way down).
- Play until what is displayed on the upper screen changes.
- Press the HOME Button and transition to the HOME Menu.
- Turn the 3D depth slider on (move the 3D depth slider all the way up).
- Launch the built-in Game Notes applet and check the screenshot it took of the upper screen of the application.
Stereoscopic Display
3D Depth Slider
HOME Menu
HOME Button
3.6 Using the ImageDb Library
Note the following cautions when using the ImageDb library. These cautions are also described in the ImageDb Programming Manual, which is included in the ImageDb package.
- If you would normally save a stereoscopic screenshot but stereoscopic display is disabled, then save only a JPEG image for the screenshot.
- The ImageDb library can also load images other than photos taken by Nintendo 3DS Camera. Therefore, you must take measures such as the following to ensure the normal operation of your application after loading images of dimensions other than 640x480.
- Scale, trim, or otherwise transform the image to ensure it will display properly.
- Do not load images whose dimensions are not supported by the application.
- When saving a screenshot within an application, use the imgdb::JpegMpBaseSaver::SetScreenshotFlag function to set the screenshot flag to true so that the screenshot is displayed by the “Games” slide show theme in Nintendo 3DS Camera.
The screenshot flag should be set to false with the imgdb::JpegMpBaseSaver::SetScreenshotFlag function in any scene where it is impossible for objects unique to the application to be included in the image. Pure camera images fall under this category. However, if an object appears and disappears depending on timing during a scene where cameras are used, this should be interpreted as "a scene where objects unique to the application can be included in the image," and you should use the imgdb::JpegMpBaseSaver::SetScreenshotFlag function to set the screenshot flag to true. An example for this is switching back and forth from AR display. You do not need to toggle the screenshot flag every time the object appears and disappears.
Setting the screenshot flag is optional in cases where the application does not use a display buffer but instead saves an independent buffer as a JPEG file. When deciding whether to handle an image as a screenshot, base your decision on whether the user would naturally think of the image as a screenshot. For example, if the image in question is captured from a game with added text at the bottom, it would normally be considered a screenshot. If the image was a QR Code that was generated from information pulled from the same game that would most likely not be considered a screenshot.
ImageDb Library
Nintendo 3DS Camera
Photos
JPEG
Screenshots
Slide show
imgdb::JpegMpBaseSaver::SetScreenshotFlag function