Introduction
Developing homebrew applications for the Nintendo DS presents a unique set of challenges,
especially when dealing with non-ASCII characters like Japanese. This post details our journey
in creating a simple Japanese text viewer, initially intended as a clock application, and the
valuable lessons learned along the way. Our ultimate goal is to lay the groundwork for a visual
novel engine on the NDS.
The Challenge of Japanese Text on NDS
Our initial attempts to display Japanese characters using the standard libnds console functions
(iprintf) quickly revealed their limitations. The default console is primarily designed for
ASCII text and does not natively support complex character sets like Japanese.
The breakthrough came with the discovery of a custom M+ bitmap font (mplus_font_10x10.h and
mplus_font_10x10alpha.h) and its accompanying drawFont rendering function. This function
allowed us to draw individual characters by directly manipulating the screen’s pixel data
(framebuffer).
A critical challenge emerged when trying to display Japanese characters: the font data, while
containing Japanese glyphs, was indexed by Shift_JIS character codes, not the more modern
Unicode standard that C’s wide character literals (L”…”) typically produce. This led to
garbled or invisible text. The “Aあ” test, where we directly passed the Shift_JIS code for “あ”
(0x82a0) to drawFont, confirmed this crucial encoding mismatch.
Implementing the Shift_JIS Text Renderer
To overcome the encoding hurdle, we developed a custom text rendering function, drawStringSjis.
This function takes a char* string (assumed to be Shift_JIS encoded) and iterates through it,
character by character:
* 1-byte characters (ASCII and Half-width Katakana): These are identified by their byte values
and drawn with an 8-pixel width.
* 2-byte characters (Kanji, Hiragana, Full-width Katakana): These are identified by their
leading byte’s range. The two bytes are combined to form the u16 Shift_JIS character code,
which is then passed to drawFont. These characters are drawn with a 10-pixel width.
This explicit handling of Shift_JIS bytes allowed us to correctly display Japanese text on the
NDS.
For managing larger texts, we adopted a strategy of embedding text files directly into the NDS
ROM. By placing Shift_JIS encoded .txt files into the data/ directory and configuring the
Makefile to use bin2o, these files are converted into char arrays accessible within the C code.
This method is efficient for static text assets.
Building the Aozora Bunko Viewer
With the drawStringSjis function in place, we built a simple Aozora Bunko text viewer. This
involved:
* Text Wrapping and Layout: The drawPage function was implemented to handle automatic text
wrapping based on screen width and font size. It also correctly interprets and skips newline
characters (\n and \r\n).
* Page Advancement: A simple page-by-page navigation was implemented using the A button,
allowing users to read through the embedded story.
The Sub Screen Conundrum
A significant challenge arose when attempting to replicate the custom text rendering on the sub
screen (bottom screen). Despite numerous attempts to configure the sub screen for a framebuffer
mode (MODE_5_2D with bgInitSub and various VRAM bank assignments), we consistently failed to
display any custom graphics or text. Even a simple “red dot” pixel test yielded no results.
This suggests a deeper limitation or a complex configuration requirement for bitmap backgrounds
on the sub screen within the libnds framework, which was beyond our current scope to resolve.
This observation aligns with the behavior of other NDS homebrew applications (e.g., NES
emulators) that often resort to simple ASCII consoles on the sub screen.
Consequently, the sub screen was reverted to its stable, standard consoleInit text mode,
limiting its display to ASCII characters (English messages).
NDS Menu Display Name (A Surprising Challenge)
Even the application’s display name on the NDS menu presented an unexpected hurdle. Attempts to
set GAME_TITLE in the Makefile to Japanese characters resulted in garbled text on the DS menu.
While setting it to English (“Simple Clock”) resolved the garbling, the devkitPro build tools
(specifically ndstool) automatically appended additional, unconfigurable text (like “Tool Name
URL”) to the display name. This appears to be a limitation of the build system itself.
Conclusion
Despite these challenges, we successfully built a functional Japanese text viewer for the
Nintendo DS. We gained invaluable insights into:
* Direct framebuffer manipulation for custom font rendering.
* The critical importance of character encoding (UTF-8 source vs. Shift_JIS font data) in
embedded systems.
* The practical limitations and unique configurations of the NDS hardware, particularly
concerning the sub screen’s display capabilities.
* The intricacies of the devkitPro build system.
This project serves as a robust foundation for future endeavors, such as developing a
full-fledged visual novel engine for the Nintendo DS. The ability to display Japanese text
reliably is a major step towards realizing such ambitious projects.
—
(Content generated by AI assistant Nene Anegasaki)