About Chinese NDS games

Sinicization is a very technically difficult job, if you don't have the foundation of Sinicization in the GBA era. Then, it is very difficult to complete the sinicization of a game independently.

By the way, I have also participated in the cracking of a certain group of games. If I know something, I will just say it casually. In general, it is divided into several steps: 1. Cracking the game, 2. Text export, 4. Translation, 6. Testing

Cracking the game, such as where is the font, where is the picture (corresponding to those pictures respectively), where is the text area and where is the sound effect area ... If the file system is a complicated ROM, what are the contents of different files? In addition, different texts of some games correspond to different fonts, which are the contents that need to be carefully confirmed. Some Roms may have compressed contents. If these contents are related to the needs of localization, it is necessary to test decompression and compression. Generally, at this stage, I will prepare several large pieces of paper for detailed records, which will bring great convenience to the future work. 2 font derivation is the most critical part related to the possibility of sinicization. The font of general games is divided into complete font and simplified font. The complete font contains more than 7 characters (including more than 6 Chinese characters), while the simplified font generally contains only 1-2 characters actually used in the game. No matter which font, due to the lack of many commonly used Chinese characters in Japanese characters, it must be revised, and the simplification of the font needs great transformation or even expansion. Later, I will specifically explain the font HACK, so I will stop here for the time being. 3. The test of Chinese text is to replace the original Japanese content with Chinese, so it is necessary to test the possibility of this replacement. Of course, the initial cracking doesn't have to be a serious text export and import, or translation modification, just look at the possibility of modification. Many of the tutorials mentioned above involve this operation, which can be studied carefully. 4. The main purpose of image HACK is image assembling and color plate processing. Other key pictures that need to be sinicized (there are contents in the pictures that need to be sinicized) must be found out. In addition, you may need to do a good job in preparing for color plate export and picture export. You can also experiment with some picture modification. If the above part is ready to be completed and the test is successful, congratulations, this sinicization project has become possible. We can move on to the next step.

The next step is to learn CT.

The full name of CT is Crystaltile, which is the result of continuous improvement by Crystal of Angel Group on the basis of the previous Tile tool. It can be said that it is a very useful tool for Chinese GBA/NDS games. In addition, it also integrates many useful functions, such as difference search, LZ77 decompression, etc., and it is specially optimized for Chinese NDS games. In addition, the version of this tool is constantly revised and updated. I used the mid-May version, and several versions were updated when writing this article. In fact, some operations of the previous TILE tools are common on CT, and those tools have some online tutorials, but for those who have not been exposed to them, they are also introduced as the new tool of CT, so I will briefly introduce them here. The following is the interface of CT: ① The area is the main part of the navigation bar, and the most important thing is the offset address, that is, the offset address, and there is also the color format, which is related to whether the contents of the graphic part of ROM can be viewed correctly. The commonly used Chinese NDS games are 1bpp monochrome, GBA 4bpp and GBA 8bpp (1bpp monochrome is mainly aimed at the contents of the font). ② The area is the display color plate, which is related to whether the corresponding colors in the graphic can be displayed correctly. You can adjust it in the palette menu or return to the default. Click on the color directly, and you can modify it directly. If it is a non-256 color swatch, the upper tie rod can also read different parts of the total color swatch (256 colors) for matching. ③ The area is TILE tool, which can be modified simply. At the same time, CT also integrates the powerful function of generating font through code table. (If you don't use the TILE function at ordinary times, you can hide this window to make room for work.) The content in the middle is the open ROM. Now the ROM is opened in TILE mode, that is, you can directly observe the TILE content (font, graphics ...). Below the menu bar are shortcut toolbars, namely ① Export button, which allows CT to export the selected content to a file with a certain format. Commonly, the content of the selected graphics area is exported as a BMP file, but the export function of CT is not limited to exporting pictures. The specific content will be further explained in the picture H tutorial. This article only needs to have a general concept. (2) the import button, the modified pictures, such as BMP pictures, import back to the specified area in the ROM. ③ Quick switch button of hexadecimal editor can quickly switch to hexadecimal mode ④LZ77 decompression button, decompress the selected LZ77 content ⑥ LZ77 compression button, ⑥ Convert the color channel into 16/32 data import ⑥ Export the color channel stored in hexadecimal mode to PAL color channel file ⑧ Dye the code ⑨ Apply code table switch, among which ④ ⑥ ⑧ ⑨ Only in 199;. Open the view menu, and you can switch the view of the working ROM to other modes. Let's switch to hexadecimal mode and see the hexadecimal editing function of CT. CT is very similar to the general hexadecimal editor (though not as powerful as UE), but it is optimized by combining with localization. Such as code dyeing. It is very convenient to view, and experienced artists can even find the beginning of color channel data directly through the dyed code, and export the color channel (which will be further introduced in the later art tutorial). In addition, in the middle of the text area, it is also easy to find the contents of special control symbols (for example, the control symbols such as F1FF in the following example are dyed light blue, which is different from ordinary text). Another very useful function is to directly insert the code table to display the general content of the text area: there are two kinds of code tables corresponding to NDS games: the standard Shift-JIS code table with 814 = spaces and the continuous code table with = spaces (the related contents of the code table will be introduced in the following tutorial). You can boldly set it to see if you can find the text area. For example, the super knife is to use the code table with = space. After nesting, you can probably see the contents of the text area in the hexadecimal mode of CT by applying the code table. This is very necessary for reading ROM. Another useful function of CT is NDS file system. Through this system, the file structure of NDS can be seen intuitively, and some Roms even store files of different types and uses in a more detailed way, which is very useful for understanding the structure of ROM. In addition, in the file system column, you can export and import files of different parts, analyze and modify them respectively. There are many powerful functions of CT, so you should explore them slowly in your application. In a word, I think that people who open this tool can probably crack 99% GBA/NDS games as long as they are not ROM with unconventional compression and encryption ... Second, let's talk about the TILE operation of CT with a simple example. Generally, after finding a rough picture in CT, adjust the window size (the shortcut key SHIFT+ direction, but the latest version has modified the shortcut key of this function, please read the description of the new version for users who use the new version). In addition, it is recommended to use about 2 for the scaling value (the old version uses 1-digit value to display the scaling ratio). This can be adjusted to a more neat situation. (The picture below has been adjusted) But the color you see at this time is not correct, because the default color channel is not suitable for all graphics (normally it is not suitable, but it is relative and eye-catching). If you want to observe it better, I suggest that you prepare a black-to-white color plate (the specific color plate establishment method is left in the art tutorial), so that the graphics can eliminate the interference of color and be easier to find, which is very convenient when the color plate is not determined. Of course, 8bpp(256 colors) and 4bpp(16 colors) should be prepared to adapt to different formats of pictures. Ok, back to the above, as long as the correct color plate is inserted, then the picture can be displayed normally. (Of course, for the ROM interpretation stage, it is not necessary to put the correct color plate on each picture.) But it seems a little flawed, because the address offset is not accurate yet. Use the shortcut key: CTRL+ arrow keys to fine-tune the address offset, which is very important. After adjustment, you can see this effect by hiding the unsightly grid. With the above method, you can get a general idea of the structure of ROM. Combined with NDS file system, we can get a general idea of what each file contains, and the key is the address of this content in ROM. In addition, it is necessary to further analyze the specific location of each content, prepare a few sheets of white paper, and carefully record what the contents of each area of ROM are, for example, list them in order of address location: XXXXXXXX-XXXXXXXX is a headline picture, 8bppXXXXXXXX-XXXXXXXX is a subtitle picture, and 4bpp xxxxxxxxxxxx-xxxxxxxx is a full-length portrait of a character. 8bppXXXXXXXX-XXXXXXXX is the font, 1 bpp xxxxXXXXXXXX-XXXXXXXXxxxx is the text area xxxxxxxxxxxx-xxxxxxxxxxxx is the sound effect ........................................................................... This record is very important, on the one hand, it can be convenient for you to find the parts that need attention at any time, and on the other hand, it has a very important function: For the content of this article, you can refer to the relevant part of the tutorial introduced in the first sentence, and then learn some related knowledge of text and code table. At last, I have entered the part with a little technical content .................................................................................................................................................................. The principle is that the text area of ROM is written in hexadecimal code. For example, the hexadecimal code corresponding to "Check 2 years ago" in the above figure is the five groups of hexadecimal codes of CD CEB 9B9 471 3E6 137 in line 76f. And the code table is a list indicating that CD=2CEB= = year 9B9= = first 471 = の 3E6 = check 137 = check such a conversion relationship. In the game, characters are selected from the font and displayed on the screen through such a conversion relationship. If the coding of the above text area is changed to CD CEB CEB 471 3E6 137, the game will also be displayed as "Check every two years", which is also the basic principle of text modification in Chinese. (The word "inspection" in the original text is not simplified, so I simplified it for the convenience of explanation. ) Generally, the Japanese version of the game uses the Shift-JIS code table. A complete Shift-JIS code table starts with spaces, punctuation, special symbols, English letters, Hiragana, Katakana, Japanese characters ... for example, 814= 8141=, 8142=. 8143=,8144=.8145=·8146=:8147=; 8148=? 8149=! 814a = ゛ 814b = ゜ 814c =' 814d =' 814e = ... TBL files stored in such a corresponding relationship as above (which can be opened and edited with WINDOWS Notepad). As mentioned before, there are two main ways to represent a general complete Shift-JIS, as shown below, from 814 =. Generally, the Chinese characters in a complete Shift-JIS code table start with "Cuo" and end with "Xi" (the most complete one ends with "black", that is, there is a paragraph after "Xi", but in general, because it is not a common word, many games have removed the part after "Xi"). The following is the analysis of these two code tables: it is not difficult to find a problem by this comparison. The code table with 814 = space is not continuous, but skips XX-XX3F, XX7F, XXFD, XXFE and XXFF (observe the part with blank lines in the middle of the first code table). And the second code table is completely continuous. Why? I believe that as long as you observe a few more text area codes, you will find the problem. For the text of the first code table, skipping these areas can effectively prevent dislocation and confusion, and in addition, codes can be reserved for half-width characters, control symbols and so on. The control symbols of the second code table mostly use the codes after FF as the control symbols. The above is the code table for exporting text. As long as you can put on a correct code table, you can export the text part. However, after translation, the original characters may not be used (it should be "definitely not") or only used, because after sinicization translation, many Chinese characters that are not available in the original font library will be used (for example, many onomatopoeic words are not available in Japanese, for example, are you, la, um ...), and most Japanese Chinese characters are traditional characters. To make a simplified version, the characters in the font library should be simplified. So what should I do with the new words after translation? The simplest thing is to add new characters to the original font, but it will be a waste of space if you just add them, because many original fonts are not used after translation. For example, there are more than 6, Chinese fonts in the complete Shift-JIS font library, but after normal translation, the actual Chinese fonts are only about 2,-3,. After localization, because the content is different from the original font library, all the fonts that need to be used can be replaced. But the problem comes again. After these new fonts are written in, how can they be linked to the coding in the text area? This requires a new code table method, which re-uses the font of the font and the coding of the text area, which requires re-editing a new code table. Give a simple example. For example, the word "check 2 years ago" above was changed into "check 2 years ago" after Chinese translation, and I had to find a place to put it. For example, the original code table was 4E3= 亜, and the traditional word "亜" was not used after translation, so I just left it in the font. Change the original code line CD CEB 9B9 471 3E6 137 "Inspection 2 years ago" to "Inspection 2 years ago": CDCE94E3E6 137. Then the game will extract the modified word "de" from the original 4E3= "Cue". And this new correspondence between the code table and the font is the code table for importing text, which is the modified code table. This requires re-editing a code table. The above is a brief introduction to the code table. After having a general concept, let's turn to the font part. Let's briefly understand the font and